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Windows 2000 e Windows Management Instrumentation 


Biztonság ? Kerberos 
Jogi Esetek e Teadélután a BSA-val 





öszonrő s Digitális rozsda 


Valamikor réges-régen, amikor a Windows 
2000-t még Windows NT 5.0-nak hívták 
(1998, Beta 2), belekezdtem egy szakkönyv 
írásába az újdonságokról, mely ugyan soha- 
sem készült el, de kiváló előszót kanyarítot- 
tam hozzá a fenti a címmel. Akkoriban dü- 
höngött az NT 5.0 mánia, a Microsoft meg- 
kezdte a Microsoft Certified Trainerek átkép- 
zését, hogy egy fél évvel később a Beta3 
megjelenésekor legyen, aki a tömegesen fel- 
lépő tanulási vágyat kielégítse. Én magam is 
azt hittem, az áttérés pillanatok alatt meg 
fog történni, hisz maga a nagy Boeing is áttért. (Itt jegy- 
zem meg, hogy a Boeing mindent azonnal kipróbál. Talán, 
mert Seattleben van a központja? ;)) A könyvkezdemény 
előszavában sorra vettem azokat a fantasztikus újdonságo- 
kat, amelyek a Windows 2000-t oly naggyá teszik: Kerberos, 
RRAS, Active Directory, IPSec, dinamikus lemezkezelés, 00S 
stb. Akkoriban a fantasztikus újdonságok nagy számában 
láttam az áttérés vonzerejét, s levontam a következtetést: 
az NT4-et bizony kikezdte a digitális rozsda, magyarán er- 
kölcsi elavulása a napnál világosabban látható. 

Ma már tudjuk: a Nagy Áttérés valahogy nem következett be 
azonnal, a Windows 2000 megjelenésének pillanatában. 
Nem úgy reagált a piac, mint a Windows 95 megjelenése- 
kor, s noha ma már valóban szép számban találunk Windows 
2000-t a vállalatoknál, azért továbbra is az NT4 a ,király". 
A cégeknek nem kellettek a fantasztikus fícsörök. Az áttér- 
tek között elhanyagolható számban találunk olyanokat, 
akik valóban használják, és kihasználják a Windows 2000 
fantasztikus szolgáltatásait. A többség pedig még mindig 
vár. Ki az első javítócsomagra (Ébresztő! Már kijött!) , ki ar- 
ra, hogy legyen legalább egy munkatárs, aki ért hozzá, ki 





csak úgy. Így telt el egy év. S noha még mind a mai napig 
találunk olyan hardvert, melynek eszközmeghajtója ,.co- 
ming soon", azért ez ma már inkább csak kivétel. 

Az áttérés most indul. Nem a Microsoft által elképzelt idő- 
pontban, tempóval, okokból és motivációkkal. A Windows 
2000 bevezetése a Microsoft híresen ügyes marketingeseinek 
nem vált dicsőségére. Az áttérés fő motivációja nem a soksok- 
sok okos-ügyes újdonság vonzása, hanem az emberi lustaság! 
Talán még emlékeznek Kedves Olvasóink arra a Dupla KV-ra, 
amit teljes egészében a DNS-nek szenteltem. Akkor azon 
,dühödtem be", hogy a NetAcademia Windows 2000 levele- 
zési listán minden második kérdésre azt kellett válaszol- 
nom: DNS (egy csomó Windows 2000 ,,hibajelenség" eltünte- 
tésének módja a DNS helyes megtervezése és beállítása). Az 
utóbbi két hónapban pedig megszámlálhatatlan olyan kér- 
dés érkezett, hogy ezt-meg-azt hogyan kell megoldani NT4 
alatt. Például hogyan lehet statikus bróz (Browse) listákat 
csinálni, mert amit az NT produkál, az használhatatlan. 
A kérdések 709o-ára ezt a választ tudtam adni: 

1. NTA4 alatt sehogy, de az biztos, hogy ingyen nem (értsd: 

kiegészítő szoftvert kell vásárolni) 
2. Windows 2000-rel ingyen, két egérkattintással 
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Például hogyan lehet NTA alatt: 
9 al-rendszergazdákat kinevezni a tartományban? 
logon mellett logoff scriptet futtatni? 
kvótát beállítani az NTFS partíciókon? 
az Internethasználatot belső IP címekre alapozni? 
automatikusan szoftvert telepíteni? 
megakadályozni, hogy LOpthCrack-kel el lehessen lopni 
a hálózatról a jelszavakat? 
optimalizálni a tartományvezérlők hálózati forgalmát 
lassú vonalakon? 
"6 rendszermentést készíteni, de NEM szalagra? 
Ez a digitális rozsdának egy másik aspektusa. Nem a kiemelt új- 
donságok teszik naggyá a vevők szemében a Windows 2000-t, 
hanem azok a mindennapi munkát segítő dolgocskák, ame- 
lyek már sohasem fognak megjelenni a Windows NT-ben. 
Két lehetőség kínálkozik tehát azok számára, akik az 1996- 
ban megjelent, de valójában belső felépítésében 1993 óta 
változatlan , öreg" NT-vel kívánják megoldani a 2001-ben 
felmerülő igényeket, s mindkét változat pénzköltéssel jár: 
1. Vagy megveszik az éppen hiányzó szolgáltatást egy kül- 
ső gyártótól, s ezzel egy pár hónapra lélegzethez jutnak 
2. Vagy megveszik a Windows 2000-t egy ,hangyányit" 
drágábban, de ezzel végleges megoldáshoz jutnak. 
A levelezési listák tanúsága szerint sokan választják az el- 
ső megoldást, s készítik fel NT4-üket kvótázásra, szoftver- 
telepítésre, vagy logoff script futtatására. De ez a lépés 
csak addig kifizetődő, amíg fel nem bukkan az újabb igény, 
amihez újra kiegészítő szoftvert kell vásárolni, és végképp 
dugába dől, ha meg akarunk szabadulni az NTLM hitelesí- 
téstől - erre nincs semmilyen külső megoldás. 
Sokan gondolhatják, hogy én itt és most a Windows 2000 
mellett lobbyzok. Még ha a látszat ez is, valójában saját ké- 
nyelmem biztosítása érdekében mondom, amit mondok: 
Emberek! Hagyjuk már békében pihenni a jó öreg, fogatlan 
oroszlánt, az Entinégyet! Szegény kisnyugdíjas Entinégyre 
ne akasszunk félmázsás betontömböket, s ne várjuk, hogy 
ezek hatására megfiatalodik! Ha a hálózat úgy kívánja, 
ugyan fontoljuk már meg, hogy az Entinéggyel küzdünk a 
sávszélesség kordában tartására, vagy a Windows 2000 te- 
lephelyeit használjuk! Hadd felejtsem már el a Replication 
Governor értéket a regisztrációs adatbázisból, a RegSave, 
RegRest vackokat a registry fájlba mentésére, a globális 
rendszergazdai jogkört, a különböző olcsó proxykat, a Net- 
BIOS-t, a WINS replikációt! 
Vegyük tudomásul, hogy az NT-t nem arra tervezték, hogy 
nagyvállalati környezetben helytálljon! Bizonyíték erre a 
Browser Service, amelyben a pillanatnyi állapot sohasem a 
valóságot tükrözi: kikapcsolt gépek virítanak a listában bol- 
dogan, míg futó gépeknek nyomuk sincs. Ezt megreformálni? 
Minek? Hol az Active Directory? Hadd öleljem a keblemre! 
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Végleges nevet kapott a 
Whistler és az Office 10 

A Whistler végleges neve Win- 
Microsoft x dows XP, míg az Office-szé 
Windows P Office XP lesz. Az XP rövidítés 
az angol , experience" szóra utal (magyarul: tapasztalat, jár- 
tasság, élmény). A Windows és az Office új verziói a .net 
jövő első komoly építőkövei. Az első félév végén megjelenő 
Office XP és a második félévre várt Windows XP továbbra is 
a hatékony csoportmunkát, kreativitást és a modern szol- 
gáltatásokat tartja szem előtt. 





Újfajta másolásvédelem a Windows XP-ben és az Office 
XP-ben 

A Microsoft bemutatta a Windows és az Office új generáció- 
jában megjelenő másolásvédelmi funkciókat. Eddig egy re- 
gisztrációs kulcs segítségével az adott terméket akárhány 
számítógépre, akárhány példányban lehetett telepíteni. A 
telepítéseknek egyedül a licencek jóhiszemű betartása sza- 
bott gátat, azonban fizikailag semmi nem akadályozta meg 
a kódok újabb és újabb felhasználását. 

A Product Activation nevű új megoldás először, mintegy 
próbaképpen az Office 2000 néhány nemzetközi változatánál 
jelent meg, és lett sikeres - természetesen nem a kalózfel- 
használók körében. A megoldás lényege, hogy a szoftver te- 
lepítésekor a számítógépben található bizonyos eszközök tí- 
pusából, azonosítóiból egy számsort generál. Az, hogy a 
számsor milyen eszközök azonosítóiból készül, nem nyilvá- 
nos, így azt sem lehet tudni, hogy egy alaplap- vagy pro- 
cesszorcsere esetén szükség van-e az újbóli regisztrációra. 


a 
jazszststk kásás bágttsákát ra 
Tia vázáró vél gida Vou iroughi the product ástvation procááá, 5] 

"Youhave not yet activated your copy of Microsoft Office Beta 2. This product will run 50 
ETT MG VON HA Et ESA ELEVE ELÉBE GRÉT AREAS NÉNK MNGTHÉR 
Kö 
"Would vou lke to activate through the Internet or by other means? 
G Actívate by using the Internet 
€C activate by using the telephone 
If you are not already connected, ezdépizj rez enpelézezépegtétreebzetezmletel et ealngaáreró 
"connection to process your information. Or, you can connect to the Internet marwually and then contírme 
"with the wizard. 1f you do not have access to the Internet, choose the option to use the telephone. 
tie tet ethrake Later 





A Microsoft a generált számsorhoz adja a regisztrációs kul- 
csot (ehhez a jelenlegi tervek szerint interneten vagy telefo- 
non juthatunk hozzá, és valószínűleg Magyarországon is lesz 
regisztrációs központ), és a kulcs beírása után már a teljes 
értékű szoftverek állnak rendelkezésünkre. A regisztráció- 
hoz a béta verzióban tapasztaltak szerint egyedül az ország 
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Windows XP 


nevére van szükség, se a mi nevünk, se a cégünk nevének 
megadása nem szükséges. A kulcs hiányában a Windows 30 
napig, az Office pedig 50 indítás erejéig használható (per- 
sze ezek az értékek a végleges megjelenésig még változhat- 
nak). A türelmi idő lejárta után a programok funkcionalitá- 
sa csökken, de úgy, hogy az adatvesztéshez ne vezethes- 
sen. Az OEM számítógépek vásárlói előre regisztrált szoft- 
vert kapnak, míg a nagyvállalati felhasználók többször 
használható, közös kódokhoz juthatnak majd hozzá. 


Nyilvános lesz Whistler (Windows XP) béta 2 

A Computer Reseller News (CRN) jelentése szerint készül a 
Whistler béta 2 változata, ami a következő hónapokban nyil- 
vánosan is elérhető lesz majd. A Microsoft igyekszik a 
Windows új változatába a lehető legtöbb .net-funkcionalitást 
zsúfolni, hogy az új operációs rendszer méltó és hasznos 
alapja lehessen a Visual Studio .NET alkalmazásainak. A CRN 
szerint a béta 2 változatban megjelenik az új felhasználói 
felület, a DirectX 8, a Windows Media Player 8, az Internet 
Explorer 6.0, valamint jónéhány újítás, köztük például egy a 
beépített tűzfal. A végleges változatot a második félév ele- 
jén, esetleg a harmadik negyedévben várhatjuk. 


il vegetsgauuti 
:d] 





a Lapzárta után érkezett: a Microsoft február 13-án 
megnyitotta a Windows XP béta webhelyet [1]. A fenti 
ábra a Windows XP új felhasználói felületét (Luna) 
mutatja 


A Windows XP webhelyén további ábrákat és leírásokat 
találhatunk az új operációs rendszerről, a SuperSite for 
Windows [2] pedig további érdekességekkel szolgál. 


Új csillag a .net egén: Car.NET 

A .net betör az autókba is: a Microsoft Car.NET néven ismert 
programja a Windows CE for Automotive 3.0 segítségével 
lehetővé teszi, hogy az autóban se maradjunk le a legjobb- 
ról: ha már vezetni nincs kedvünk, kedvünkre e-mailezhe- 
tünk, vásárolgathatunk, vagy éppen letölthetjük kedvenc 
együttesünk legújabb számait. A szövegfelismerésnek kö- 
szönhetően nem kell attól félnünk, hogy a matatás elvonja 
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a figyelmünket az útról, sőt, a gépelést vagy szövegolva- 
sást igénylő funkciók egyáltalán nem is működnek. 

A fejlesztést segítik a teljes Car.NET Framework, az ezzel 
kompatíbilis Car.NET eszközök, a Car.NET Server (vagy ha 
úgy tetszik, Microsoft Mobile Information Server for Automo- 
tive) és a hamarosan - sajnos, valószínűleg nem nálunk - 
megjelenő Car.NET Services, azaz szolgáltatások. A témáról 
megjelent sajtóközlemények között lehet tallózni - többek 
között - a [3] és [4] címeken. 


jownload a SharePoint Portal Server RC1 

peli . Megjelent ([5]) és letölthető ([6]) a 

ISarvorRCL korábban Tahoe Server néven ismert 
portál, a Microsoft SharePoint Portal Server RC1 béta verzió- 
ja. Az új változat a névváltoztatás mellett több újdonságot 
is tartalmaz. A legfontosabb talán az, hogy az igéretek sze- 
rint erről a változatról már lehet majd véglegesre frissíteni. 
Bár kipróbálni még nem volt alkalmunk, arra felhívjuk a fi- 
gyelmet, hogy a Tahoe korábbi változatai nem fértek össze 
az ugyanazon gépre telepített Exchange 2000 Server-rel! 


Security 
la Shared Content 
ssyzftb 
éb ez 
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view 








Browser View 


a Az új dokumentumkezelő-rendszert az Office új 
verziói is támogatják majd 
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to 
sem maradnak .net támo- e 
gatás nélkül. A Java User 


Migration Path to Microsoft .NET (JUMP to .NET) csomag 
számos megoldással segít belépni a .net világba. A JUMP 
to .NET eszközkészlete három fő részből áll, az első a J--- 
és a .NET platform közötti együttműködést teszi lehetővé, 
a második Visual Studio .net eszközöket tartalmaz, ame- 
lyek lehetővé teszik, hogy a J--- projekteket a Visual Stu- 
dio .net-en belül is felhasználhassuk; a harmadik csoport 
pedig a J--- projektek Ct-ba konvertálását segíti. 

A JUMP to .NET még nem érhető el, a béta változat meg- 
jelenését 2001 első félévére, míg a végleges verziót a má- 
sodik félévre igérik a fejlesztők. A témáról részletesebben 
a [7] és a [8] címen olvashatunk, akit érdekel a béta ver- 
zió, írjon levelet a [9] címre. 


dada kele E Le UT G Ae 

[1] http://www.microsoft.com/windowsxp 

[2] http://www.winsupersite.com/reviews/whistler 2416.as 

[3] http://www.microsoft.com/PressPa: 2001 
jan01/01-O8auto.asp 

[4] http://www.microsoft.com/PressPass/press/2000/Oct00/ 





JUMP to .NET! 


A Visual J4-- nem lesz része Ju 


a .net platformnak, a Jr 
programozók azonban még- 


CarNetPR.asp 
[5] http://www.microsoft.com/shar. 
[6] h icrosoft.C. sharepoint/eval. 
[7] http://msdn.microsoft.com, mp/default.as 


[8] Help /msdnimertso ton ÚJ p TATA, 
[91 jumpbeta 2microsoft.com 


http://vilagokorseg.hu 








MEG EGYÉBKÉNT IS, GONDOLJ 
BELE, A ROLLS ROYCE-HOZ IS 
SOFŐR JÁR - A MANAGER 
HELYETT IS ELVÉGZI MÁS A 
PISZKOS MUNKÁT. 


ÉS MIITT A ROLLS ROYCE? 


BŐRKÖTÉSŰ TIME MANAGER. 
TERMÉSZETESEN ARANYÁR- 
BAN, MERT EGYÉBKÉNT NEM 
LENNE STÁTUSSZIMBÓLUM. 






NA MIT SZÓLTOK, MILYEN 
CSINI PALMTOPOM VAN! 


IGAZI MANAGER NEM 
HASZNÁL ILYET. MÉL- 
TÓSÁGÁN ALULI, HOGY 
DRÁGA IDEJÉT TECHNI- 
KAI NAPRAKÉSZSÉGRE 
PAZAROLJA. 

















IGAZÁBÓL EGY VACAK NOTESZ 
IS ELÉG LENNE, DE CSAK KE- 
VESEN BÍRNAK AKKORA TEKIN- 
TÉLLYEL, HOGY EZT MEGEN- 
GEDHESSÉK MAGUKNAK. 


ERGO MINÉL KISEBB 
VALAKINEK A VALÓDI 
TEKINTÉLYE, ANNÁL 
IMPONÁLÓBB JEGY- 


ZETTÖMBBEL KELL 
A MEGBESZÉLÉSEK- 
RE JÁRNIA. 
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WINDowS 2000 b 


PING, PING, PING 

Mai élveboncolásunk első alanya egy jó nagy ping lesz. Mé- 
retét tekintve akkora, hogy semmiképpen sem fér be egyet- 
len, maximálisan 1514 bájt méretű keretbe. A kísérlet azért 
fontos számunkra, mert a való világ valós adatainak többsé- 
ge lényegesen nagyobb, mint 1514 bájt, így - mint csepp a 
tengerben - e jókora pingen felfedezhető ugyanaz az átala- 
kítási eljárás, ami minden nagyobb fájl esetén megtörténik, 
s amit a FONTOS.XLS is elszenved, ha hálózaton keresztül to- 
vábbítjuk - vagyis darabokra bomlik a feladónál, és ezekből 
áll össze a fogadónál. Ezt kapd el: 


PING —1 10000 www.netacademia.net 


Az itt elemzett PING letölthető az újság weblapjáról, neve: 
BIGPING.CAP. 

Először madártávlatból vessünk egy pillantást az elkapott 
hálózati forgalomra: 
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XEROX 000000 
E0E320000100 


E0E320000100 DNS 
XEROX 000000 DNS 


0x53:Std Ory 
oxs3:Sra Ory 


Ox343D; 

























E EOE320000100 IP AJOx343D; 
§. EOE320000100 IP ID z § A 
3.024258 — XEROX 000000 EOE320000100 IP ID z sp 
3.064314 — XEROX 000000 EOE320000100 IP ID z 43D; ] 
9 3.084343 — XEROX 000000 z Ox3430; l 
10 3.725245 — E0E320000100 Reply: 1 ) 
da 3.865442 — E0E320000100 OxCESB; 
12 3.965583 — EOE320000100 OxCESB; 
13 4.065724 — E0E320000100 OxCESB; 
14 4.165865 — E0E320000100 XEROX 000000 IP 
15 4.266006 — E0E320000100 XEROX 000000 IP 
16 4.346119 — E0E320000100 XEROX 000000 IP OxCESB; 
4.356133 — XEROX 000000 EOE320000100 ICHP Echo: From 219 
k Í 
[Comment For Summary Fát: 3159 A 


5 A nagy ping látképe 


Jól megfigyelhető, hogy az ICMP Echo és ICMP Echo 
Reply 2 közé további IP csomagok ékelődtek, melyekről — 
legalábbis első ránézésre - nem látszik azonnal, hogy a 
PING-hez tartoznának. Közönséges IP csomagok volnának?? 
A korábbi cikkeimben leírtaknak megfelelően egy beérkező 
hálózati csomag determinisztikus úton jut el a megfelelő 
feldolgozóegységhez, hisz minden egyes réteg pontosan 
tudja, hogy a számára feldolgozhatatlan , Number of data 
bytes remaining" adatokat hova továbbítsa. Az Ethernet ke- 
retben az Ethernet Type mező mutatja meg, hogy mit szál- 
lít az adott keret, míg például az IP-ben a Protocol mező 
végzi ugyanezt a feladatot. Nézzük tehát meg az egyik ,kó- 
sza" IP csomagot 8), hogy vajon mit tud magáról: 
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1500, Frag. 


2 


More fragments in datagram 


IP: ID - 0x343D; Proto - ICMP; Len: 


HW Offset — 1480 (0x5C8) 


IP: Total Length - 1500 (0x5DC) ( 


IP: Identification - 13373 (0x343D) 
IP: Flags Summary - 201 (0xC9) 
IP: 1... .ss 1. 
4 after this one 
IP3 sose ss 0. 5 May fragment datagram if 
4 necessary 
IP: Fragment Offset - 1480 (0x5C8) bytes 
IP: Time to Live - 128 (0x80) 
IP: Protocol - ICMP - Internet Control Message 
IP: Fragmented Datagram Data: Number of data 


4 bytes remaining - 1480 (0x05C8) (6) 


Elég sok újdonságot mutat ez a néhány, természetesen gon- 
dosan megritkított sor. Az IP fejléc Protocol mezőjéből leol- 
vasható 0), hogy az itt szállított adat tulajdonképpen ICMP, 
vagyis annak maradéka. Honnan tudjuk, hogy maradék? Egy- 
felől onnan, hogy a Fragment bit 6) be van állítva, ami tu- 
lajdonképpen nem azt jelzi, hogy az éppen nagyítónk alá ke- 
rült csomag egy töredék, hanem azt, hogy további töredé- 
kek várhatók (More fragments in datagram after this one). 
Másfelől onnan, hogy a következő olvasható a ,hasznos" 
adatok előtt 0: Fragmented Datagram Data: Number of da- 
ta bytes remaining. 

Ami pedig a NetMon lustaságát illeti (hogy csak odafigyelés- 
sel deríthető ki, hogy ez a ping folytatása) érthető, hiszen 
ICMP fejlécet nem találunk ebben a csomagban. Minek is 
kellene mind a hét utazó csomagban megismételni, hogy ez 
egy ICMP Echo? A csomagok anélkül is utat találnak felfelé 
a protokollveremben. A kérdés csak az, hogyha a gép egy- 
szerre két nagydarab, töredezett pinget kap, akkor a töredé- 
keket hogyan tudja megfelelően osztályozni, hogy honnan 
jöttek? Erre szolgál az Identification (-13373 (0x343D)) 
mező (2. Minden beérkező IP csomagban, és töredékeiben 
azonos ez a random érték. Így nincs más teendője az IP fel- 
dolgozónak, mint mindaddig ugyanoda dobálni a beérkező 
töredékeket, amíg azok Identification mezője megegyezik, 
és be nem fut az utolsó töredék, ahol a Fragment bit már 
nulla (Last fragment in datagram). 


Tördelés 

Most vessünk egy pillantást a tördelés általános menetére. Az 
alábbi ábra a PING feldarabolásának sematikus vázlata. 
Összeáll a teljes, tízezer bájtos PING, és ezt valaki csomagok 
sorozatára bontja úgy, hogy az ICMP adattartalom lesz a tran- 
csírozás áldozata - de az IP fejléc épségben megismétlődik! 
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Hasznos" adat, 10000 bájt 
Feldarabolandó 10000-ICMP fejléc 























Eth.] IP ] ICMP 


1514 bájt 


5 A 10000 bájtos ICMP Echo darabolás előtt... 








abcdefghijklmnopgrstuvwabcdefghijklmnopg 
221480 ,, 1480 , ...még 3x1480 





— 21120, 


8 1514 bájt j 

(ERETEBETEKR] abcdefoh : 1472 
[EHET ijkimnoparstuv ! 1480 
HKIlaetetotüttm ) 1480 
[En [ae] nopgrstuvwab 1480 
(En.[r] cdefghijklmno. ! 1480 
[En.[9P ] parstuvwabcdef " 1480 
fEn.[r] ghijklmn 1128 


1514 bájt 
0 .,..és a darabolás után 


A teljes átvitt adatmennyiség a fejlécekkel együtt pedig 
6x15144-1162-10246 bájt, ami már az Ethernet és IP fejlécek 
méretét is tartalmazza. Ki végzi vajon a tördelést? Az előzőek 
alapján az IP protokollra gyanakodhatunk. Más alkalmazások- 
ra gondolva beláthatjuk, hogy nem az alkalmazás darabol. Az 
biztos, hogy nem az Excel fogja szorgosan felaprítani a FON- 
TOS.XLS-t adatátvitel előtt, hisz pontosan arra találták ki a 
rétegzett hálózatni architektúrákat, hogy például a hardver 
által okozott kellemetlenségek rejtve maradjanak a maga- 
sabb szintű rétegek, s főleg az alkalmazások elől. Jelen eset- 
ben az , alkalmazás" az ICMP, előle rejtve marad a darabolás. 
De vajon miért pont az IP végzi ezt a munkát? Miért nem az 
Ethernet meghajtóprogramja? Hisz mégiscsak közelebb áll az 
1514 bájtos korlátot okozó Ethernet kártyához? 

A kérdés jó, a válasz pedig az, hogy az Ethernet fejléc 
ugyan ,közelebb" van a hardverhez, de épp emiatt kevésbé 
számíthatunk rá: amikor egy IP csomag útválasztó-hegye- 
ken át jut el egy távoli kiszolgálóig, akkor az Ethernet fej- 
léc tartóssága enyhén szólva is megkérdőjelezhető, hisz a 
legelső útválasztó lebontja, és teljesen más (például Token- 
Ring) fejlécet illeszt a csomag elé. Így a végponttól vég- 
pontig történő címzés nem bízható az Ethernetre, csak egy 
minden matatást és útválasztást túlélő rétegre - s az IP 
pont erre való. Minden töredezett csomag elején ott a he- 
lye az IP fejlécnek, hogy a töredékek mindegyike utat ta- 
láljon a célba! Az ICMP fejlécről ugyanez a nagyfokú hasz- 
nosság már nem mondható el, emiatt az már a tördelés ál- 
dozatául esik. Ha majd rátérünk a TCP csatorna elemzésére, 
látni fogjuk, hogy ott már a TCP fejléc is beleszól a szállí- 
tásba, így világos, hogy az sem fog belekerülni a darálóba. 
A következő kérdés önként adódik: honnan tudja az IP, vagy 
majd a TCP, hogy mekkorára kell tördelni? A hálózati kártya ál- 
tal elfogadott legnagyobb keret méretét, valamint az összes ré- 
teg fejlécigényét megfelelő API hívásokkal le lehet kérdezni, s 
a Windows 2000 ezt éppúgy elvégzi menet közben, mint annyi 
minden mást. De hogy egy kicsit a múltba révedezzünk. . . 


Maximum Transmission Unit 

Hajdanában-danában, amikor az operációs rendszerek még 
feleennyit tudtak, bizony néha szükség lehetett a nem (iga- 
zán) támogatott kártyák 3rd party meghajtóit egy kis INI- 
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fájl matatással megsegíteni a hatékony működés érdeké- 
ben. Volt idő, amikor a tördelési határt kézzel kellett beál- 
lítani, s ennek a letűnt korszaknak állít emléket a regiszt- 
rációs adatbázis MTU kulcsa, ahol mind a mai napig meg le- 
het változtatni kézzel a tördelési határt. 


Kulcs neve: MTU, alapértelmezésben nincs ott 

Helye: HKLMASYSTEM(CurrentControlSetlsServicest 

4 TepiplParameterslInterfaceslcsinterface-name2 

Adattípus: REG DWORD 

Tartomány: 0x44 — dinamikusan felismert MTU vagy 
OXFFFFFFFF 

Alapértelmezett érték, ha a kulcs hiányzik: 


OxXFFFFFFFF (-Autodetect) 


Ennek a gyakorlatban még sohasem vettem hasznát, egysze- 
rűen csak érdekes. Még érdekesebb, hogy míg IP szinten a 
helyi hálózati kártya MTU-jára vagyunk kíváncsiak, addig a 
TCP réteg a két kommunikáló fél között a teljes útvonalon 
érvényesíthető MTU-ra kíváncsi, s ezt le is kérdezi az útvo- 
nal teljes hosszán - ha tudja. 


Protocol Coalesce Tool 

A széttöredezett PING remek lehetőséget nyújt egy másik na- 
gyon hasznos eszköz bemutatására, amellyel nemcsak a vég- 
ponti kommunikáló felek, hanem a hálózati forgalmat figye- 
lő köztes személy is képes a töredékeket egyesíteni, s ezzel 
értékesebb adatokhoz jutni. Sajnos az egyesítő (Coalesce) 
eszköz az ingyenes, beépített Network Monitorban le van 
tiltva, így csak vastagabb pénztárcájú olvasóim figyeljenek 
jól. A vagyonosabbak ugyanis egy szakajtóderéknyi kiváló 
szakértőt (Expert) is kapnak a NetMonnal, akik különféle 
elemzéseket végezhetnek a már elkapott/elmentett hálózati 
forgalom alapján. A Tools-sExperts menüpontból indulunk 
(figyelem, a NetMon menüi változnak annak függvényében, 
hogy melyik ablakban: a fő vagy a részletes nézetben ácsor- 
gunk éppen!) ahol elénk tárul egy csomó fura szerzet, ame- 
lyekkel részletesebben majd egy későbbi cikkben foglalko- 
zom, most a töredezett ping összevonására összpontosítunk. 


METSZET a 
Group 





ANExpet: 
(ZJ Avetage Server Flesponse Time 
DJ Propey Distrbution 

E Protocol Coalesce T 

II Pidtocol Diztrtbution 
EJ TCP Retransmat 
ID Top Users 
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5 A Protocol Coalesce Tool 


A ,Protocol Coalesce Tool"-t az , Add to Run..." gombbal 
áthajítottam a jobboldalra, a lefuttatandó feladatok közé, 
s a ,Run Experts" megnyomása után máris gyönyörködhe- 
tünk, no nem az eredményben, hanem abban az útvonal- 
ban, ahova a szakértés eredménye került, ami roppant szív- 
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derítő látvány, különösen, ha a Desktopra teszi ;) 


C:Wocuments and Settingslfm.NETACADEMIAN 
S Desktoplbigping(Coalesced)02.cap 


Innen már csak egy kis egérfutkosás, és megnyitható a kész- 
termék; az összevont pingek fájlja. Vessünk egy pillantást egy 
összevont ICMP Echo-ra. Mekkora az Ethernet keret mérete? 








974187 
s 3.72sz45 


900001000000  £OR320000100  ICHP 
ZOE3ZOO0OL100  000001000000 ICHP 


Echo: From 212.97.09.40 To 2121 
Zcho Reply: To Z12.97.09.40 Fri 


2 
Bestination address : RORJZ0000100 
Source address : 000001000000 
Trane Length : 10042 (052734) 
fthernet Type : 00900 (IP: DOD Internet PfŐtoco1) 


Ethernet Data: Munber of data bytes remaining " 10028 (0x272CI 
I , 
uwvabcdefghijkim 
nopgrstuvvabedet 
ghajkinnopgrstuv 
Vabcdefghijkluno 
parstuvwabede fgh 
ijkinnopar 















CETHEPHET: 
ÖETHEPNET: 

ETHERNET: 
ETHERNET: 
RTHERHET: 


4 





75 76 77 61 62 63 €4 65 66 67 68 69 6A 6B 6C 6D 
6E 6F 70 71 72 73 74 75 76 77 61 62 63 64 65 66 
67 69 69 6A 6B 6C 6D 6B 6F 70 71 72 73 74 75 76 
77 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 
70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 
69 6h 6B 6C 6D 6E 6F 70 71 72 





afa 


5 Összevont bigping 


Amint az a fenti ábráról leolvasható, a keretméret 10042 bájt 
6), ami sokszorosa a maximális 1514 bájtnak. Az összevonás 
eredménye többé soha nem tuszkolható ki az Ethernet hálózat- 
ba, bármennyire is szabványos keretnek látszik első pillantásra, 
s bármilyen csábító is a pénzes NetMon , Transmit Frame" me- 
nüpontja. Number of data bytes remaining? 10028-10000 be- 
tű 4 20 bájt IP fejléc -- 8 bájt ICMP fejléc. Pont, mint azon az 
előző ábrán, ahol a ping darabolás előtti állapotát rajzoltam le. 
Ugyanezzel az eszközzel lehet egy, akár megabájtos keretbe 
összeszedni a hálózati forgalomban tördelve utazó dokumentu- 
mokat. De nem akarok további hackertippeket adni, haladjunk 
a korral, és lássunk más érdekességeket az ICMP háza tájáról. 


Tracert 

Gondolkodott-e már valaki azon, hogy a tracert (Trace Rou- 
te) parancs honnan a csudából tudja két távoli végpont kö- 
zött az útvonalat? Talán le lehet kérdezni az útválszatókat? 
Lehet, hogy le lehet, de honnan tudjam, hogy melyiket, hisz 
az IP-ben éppen a szabad útválasztás az egyik legnagyobb 
találmány a világon, azaz akár minden egyes IP csomagom 
más útvonalon juthat el a célállomásig. Vajon van-e esély 
arra, hogy hálózati forgalmam nem a tracert által kiírt/meg- 
jósolt irányba fog menni? Ha alternatív útvonalak vannak a 
két végpont között, és az útválasztók útvonaltáblája is lehe- 
tővé teszi, akkor bizony jó esély van rá! Aki esetleg nem em- 
lékezne rá, a tracert így működik: 


c:VStracert www.netacademia.net 


Tracing route to www.netacademia.net [212.97.8.36] 


over a maximum of 30 hops: 


1 — 510 ms 361 ms 260 ms 
4 as5200-O.ahol.com [212.97.9.1] 
2 — 351 ms 240 ms 221 ms 


4 core-if.routerO.hu.ahol.com [212.97.8.1] 


3 310 ms 240 ms 241 ms 
4, hofeherke.netacademia.net [212.97.8.36] 


Trace complete. 
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Sajnos túl közel ültem a webkiszolgálónkhoz, így a lista rö- 
vidre sikeredett, de a világ más tájairól a www.netacademi- 
a.net bizony akár 40 routernyi távolságban is lehet! A vá- 
laszban soronként láthatjuk a köztes útválasztókat, valamint 
azok (3 darab) válaszidejét. A válaszidők átlaga talán töb- 
bet mondana, de ez a jószág három különböző mérésének 
eredményét nem képes kiátlagolni, hanem szépen kiírja 
mindet egymás mellé. Például az as5200-O.ahol.com 
[212.97.9.1] nevű gép először 510 ms, másodszor 361 ms, 
végül a harmadik mérésre 260 ms alatt válaszolt. Ha a mért 
idők helyén csillagokat látunk, akkor az adott válaszidő több 
volt, mint 1 másodperc. 

Idejében elindított NetMonnal szerencsésen elkaptam a tra- 
cert hálózati forgalmát, hogy megvizsgálhassuk, vajon me- 
lyik az a protokoll, amivel routereket lehet lekérdezni. 
Igen, az ICMP-ről van szó már megint. Említettem, hogy az 
ICMP-nek rengeteg változata van, ezek közül most ismerked- 
jünk meg az Echoval... Na neeeeeeee! Már megint a ping? 
Igen, a ping fog segíteni, mert olyan érdekes módon fogjuk 
használni, hogy a router kénytelen lesz válaszolni, azért 
mert a csomag TTL-je - gonosz módon - még a célba jutás 
előtt lejár. A múltkori cikkben emlékeztem meg az IP fejléc 
mezőiről, s akkor esett szó a TTL szerepéről, ami megakadá- 
lyozza, hogy egy csomag a végtelenségig keringjen hibás út- 
választású hálózatodon. Általában egy IP csomag elég ma- 
gas TTL-lel indul útjára (128), ami elegendően nagy ahhoz, 
hogy a földet akár háromszor is körbeutazza. A tracert pa- 
rancs azonban a legelső csomagot 1-es TTL-lel adja fel, 
amely az első útválasztón azonnal halálra ítéltetik. Mit tesz 
ilyenkor a router? Akár csendben el is temethetné a csoma- 
got, de visszaszól, mégpedig - és ez tényleg új ICMP szerep - 
ICMP Time Exceeded üzenettel (időtúllépés). Ennek a válasz- 
nak a megfordulási idejéből számítódik és íródik ki a képernyő- 
re a legelső válaszidő. Ezután a tracert még két ilyen TTL-1-es 
csomagot kiküld, hogy meglegyen a három mérési érték, utá- 
na három darab TTL-2 küldése következik, majd TTL-3 és így 
tovább, amíg a TTL elég nagy nem lesz ahhoz, hogy a csomag 
eljusson a végállomásig, s az Echo-ra megérkezhessen az Echo 
Reply. Madártávlatból a folyamat így néz ki: 





KEZELTE TET TETTETETT TETT zDI2[] 
JA Ele Edt Display Iools Options Window Help ll 21 


la] : ml] SS EBBE ele] lel alkil al 2] 












E69AZ0000100 
0900001000000 
E69A20000100 
000001000000 
E69A20000100 
000001000000 
E69A20000100 
900001000000 
E69A20000100 
000001000000 
E69AZ0000100 
000001000000 
E69A20000100 
900001000000 
EGSAZ0000100 
000001000000 
E69A20000100 
900001000000 
900000000000 


295133 
805928 
805928 
166490 
166490 
426895 
178065 
S28611 
sz8611 
763986 
12 5.768986 
13 5.989329 
14 6.780561 
15 7.091045 
16 7.091045 
1419 
18 7.331419 
19 7.571794 
20 0.000000 






1001000000 
9A20000100 
0900001000000 
E69A20000100 
000001000000 
E69A20000100 
000001000000 
T69A20000100 
0900001000000 
369420000100 
000001000000 
E69A20000100 
0900001000000 
E69A20000100 
000001000000 
Z69AZ0000100 
900001000000 
369A20000100 
900000000000 






kene: 
Time Kxeeeded: 212.597.0.36 
fcho: From 212.97.09.60 To 
Time Kxceeded: 212.57.8.36 
Tcho: From 212.97.09.60 Te 
Time fxceeded: 212.97.8.36 
Keho: From 212.97.09.60 To 
Time fxceeded: Z12.57.8.36 
Teho: ] 
] 


Kene: 
eno: From 212.97.09.60 To / 
Echo Reply: To 212.97.09.60/ 
Teho: From 212.57.05.60 To) 
Teho neply: To 212.97.09.60 
fstbek té Fréses öepíréői d] 











5 A tracert forgalma 


S most vizsgáljuk meg az egyes csomagokat! Vajon a feladott 
Echo-kban mi az IP cím? Mindig a legközelebbi routerre mu- 
tat? Szó sincs róla, mindig a végcél IP címe van benne, csak 
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a csomag (az alacsony TTL miatt) nem jut el a célba. A Time 
Exceeded csomag beltartalma, részenként a következő: 


IP: ID Ox8214; Proto - ICMP; Len: 56 


IP: Precedence Internetwork Control 


A Precedence értéke megváltozott Routine-ről (0x00) In- 
ternetwork Controlra (0xC0). 


IP: Data: Number of data bytes remaining 36 
(0x0024) 
ICMP: Time Exceeded: 212.97.8.36 (See frame 2) 


ICMP: Packet Type - Time Exceeded 


ICMP: Time Exceeded Code - Time To Live Exceeded 
4 In Transit 


ICMP: 


Data: Number of data bytes remaining 


4 28 (0x001C) 


Innentől pedig megismétlődik az eredeti IP csomag, hogy 
az időtúllépési üzenetet fogadó oldalán fel lehessen ismer- 
ni, mi nem ért célba: 


ICMP: Description of original IP frame 


4 (Ox4) 


ICMP: (IP) Version 


. eredeti IP cím, checksum stb. 


A hibaüzenetet feladó gép IP címe alapján a feladó még el- 
végez egy fordított DNS lekérdezést (reverse lookup), hogy 
megtudja annak a routernek a DNS nevét (ha van), ahol a 
csomag elhunyt, majd kiírja a képernyőre. Az én esetemben 
a fordított lekérdezés azért nem látszik az elkapott hálóza- 
ti forgalomban, mert többször is lefuttattam ugyanazt a pa- 
rancsot, s míg legelőször még szükség volt a reverse 
lookupra (de akkor még nem futtattam a NetMont) , a továb- 
biakban már nem, mert a Windows 2000 ügyféloldali DNS 
gyorsítótára elmentette a válaszokat, amit IPCONFIG / 
DISPLAYDNS-sel le is ellenőrizhetünk. 

Egy kérdés maradt hátra: vajon biztosan a tracert által kiírt 
útvonalon fognak haladni csomagjaink? Mint az a madár- 
távlati képből látszott, itt egymástól teljesen független IP 
csomagok jöttek-mentek, az egyiknek kisebb volt a TTL-je, 
a másiknak nagyobb, de a feladó és a cél IP címén kívül 
más közös nem volt bennük. Ad abszurdum még az is elkép- 
zelhető, hogy minden egyes tracert csomag más úton jut el 
a számára kijelölt kivégzési pontig (ahol elfogy a TTL), így 
az útvonalinformációt - nagyobb távolságokon - igencsak 
fenntartásokkal illik kezelni. 


Pathping 

Ha valaki esetleg veszi a fáradságot és körülnéz a Windows 
2000 SYSTEM32 könyvtárában, talál ott egy pathping.exe 
parancsot, amely nagyjából ugyanazt tudja, mint a tracert 
azzal kiegészítve, hogy képes leellenőrizni az útvonal teljes 
hosszán az RSVP protokoll támogatását. Az RSVP a Resour- 
ce Reservation Protocol rövidítése, és garantált sávszéles- 
ség (005, szolgáltatásminőség) lefoglalására használható 
olyan útvonalakon, ahol minden router támogatja ezt a le- 
hetőséget. Csínján bánjunk a Pathpinggel, mert elég ala- 
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pos/erőszakos jószág! Míg a tracert beéri routerenként 3 
pinggel, addig ez utóbbi valóságos pingáradatot ereszt meg 
a célgép felé (routerenként 100 darab ICMP Echo!!), igaz, 
mérési eredményei jóval pontosabbak a tracert-től kapott 
adatoknál, hisz száz ping esetén már van mit statisztikáz- 


ni: százalékosan meg tudja mondani, melyik útválasztó 


mennyit hibázik. Az alábbi ábra azt mutatja, hogy milyen 
kiváló vonalaink vannak a Microsoft.com-ig ;) 


HEZZZETTEET TETTE 











0 A pathping eredménye 


Ennek a mérésnek a hálózati forgalma 1000 (ezer!) darab ICMP 
Echo-t, és Replyt jelentett, erre bizonyíték az elkapott forga- 
lom utolsó ,keretében", a statisztikacsomagban olvasható: 


STATS: Number of Frames Captured 2048 


STATS: Elapsed Time - 5 Minutes 18 Seconds 


4 439786 MicroSeconds 


STATS: Total Frames Captured - 2048 (0x800) 
STATS: Total Bytes Captured - 262073 (Ox3FFB9) 
STATS: MAC Frames Received z 1875 

STATS: MAC CRC Errors - 0 

STATS: MAC Bytes Received - 0x000000000009€036 
STATS: MAC Frames Dropped due to No Buffers - 0 
STATS: MAC MultiCasts Received - 30 

STATS: MAC BroadCasts Received - 26 

STATS: MAC Frames Dropped due to HardWare 

4 Errors - 0 


A statisztikacsomagot mindig a NetMon Trace utolsó csomag- 
jában, az itt felhasznált fájlokat (BIGPING.CAP, tracert.cap, 
pathping.cap) pedig a weben találják Lelkes Olvasóim. 


Fóti Marcell 
marcellf onetacademia.net 
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A Microsoft és más, vele együttműködő cégek több olyan cél- 
kitűzést fogalmaztak meg, melyek elősegítik a nagykiterjedé- 
sű PC-hálózatok tulajdonlási költségének (TCO) csökkentését. 
A TCO messze meghaladja egy elosztott PC-hálózat hardver- és 
szoftvereszközeinek beszerzési árát. A TCO-ba beletartoznak az 
üzembehelyezés, a karbantartás, a rendszerfelügyelet, a kép- 
zés, a telefonos és helybeni terméktámogatás költségei, vala- 
mint a hardver- és szoftverfrissítésekkel kapcsolatos kiadások. 
E költségcsökkentő kezdeményezések közül az egyik legfonto- 
sabb a WBEM (Web-Based Enterprise Management — nagykiterje- 
désű rendszerek Web-alapú felügyelete) , amely a felügyeleti inf- 
rastruktúrára vonatkozó szabványokat fogalmaz meg, és lehe- 
tővé teszi többféle hardver- és szoftverfelügyeleti rendszerből 
származó információk összegzését. Ez az információ aztán fel- 
használható a rendszerfelügyeleti alkalmazásokban. A WBEM a 
CIM (Common Information Model — közös információ-modell) sé- 
mán alapul, amely a DMTF (Distributed Management Task Force 
- elosztott felügyelet munkacsoport) által létrehozott szabvány. 
A Microsoft Windows Management Instrumentation (WMI, Win- 
dows felügyeleti eszközkészlet) WBEM-kompatibilis, és a Win- 
dows 2000 operációs rendszer beállításairól, állapotáról és mű- 
ködéséről összefüggő, gazdag információkkal szolgáló modellt 
biztosít. A Windows 2000 más rendszerfelügyeleti szolgáltatá- 
saival együtt használva a WMI leegyszerűsítheti az integrált 
felügyeleti alkalmazások fejlesztését, lehetővé téve a gyártók- 
nak skálázható, hatékony felügyeleti rendszerek készítését. 
Cikkünkben először a WBEM áttekintésével és kialakulásával, 
majd a WBEM szabványos összetevőivel, és a WBEM-kompa- 
tibilis Windows felügyeleti architektúrával foglalkozunk. Vé- 
gül a WMI funkciók és más Windows felügyeleti szolgáltatá- 
sok együttműködésére mutatunk példákat. 


A WBEM áttekintése 

A WBEM a nagykiterjedésű hálózatok felügyeleti információi- 
nak elérését és megosztását szolgáló szabványos, de nem sza- 
badalmazott (vagyis nyílt) megoldások kifejlesztését célzó 
kezdeményezés. A WBEM olyan megoldásokat fog eredmé- 
nyezni, melyek lehetővé teszik a különböző forrásokból szár- 
mazó felügyeleti adatok összegyűjtését, összekapcsolását és 
összesítését, és ezzel gazdagabb és pontosabb képet adhat- 
nak a nagyvállalati környezetről. A WBEM kezdeményezés cél- 
kitűzései között szerepel a nagykiterjedésű hálózatok állapo- 
táról szóló, és azok felügyeleti adatainak összegyűjtésével 
kapcsolatos problémák megoldása. Ezek a hálózatok számos 
hardvergyártó eszközeit, többféle protokollt és operációs 
rendszert, és rengeteg elosztott alkalmazást tartalmazhatnak. 
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0 Nagykiterjedésű hálózatban megtalálható tipikus 
protokollok és eszközök. 


A nagykiterjedésű hálózatok felügyelete általában különféle 
eszköztípusok változatos protokolljaihoz és csatolófelületei- 
hez kötődik (például a Simple Network Management Protocol 
(SNMP) a hálózatok felügyeletére, a Desktop Management In- 
terface (DMI) az asztali gépek felügyeletére szolgál) . A WBEM 
szerint a nagykiterjedésű hálózatok felügyeletéhez olyan 
eszközökre van szükség, melyek együttműködnek annak ér- 
dekében, hogy a felügyeleti információk összegyűjtésére egy 
egyszerű, közös modellt alkossanak. A WBEM biztosítja ezt a 
közös modellt és adatforrást, melyek bővíthetők, hogy képe- 
sek legyenek együttműködni a meglévő hálózati összetevők- 
kel, eszközökkel és protokollokkal. 


Rendszerfelügyelet 





0 A WBEM architektúra. 


A WBEM nem böngészőalapú eszköz, nem felhasználói felület, 
nem adattároló, nem hálózatfelügyeleti protokoll, nem objek- 
tummodell, és nem is regisztrációs adatbázist, címtárat, vagy 
fájlrendszert helyettesítő eszköz. A WBEM egy kezdeményezés, 
mely a nagykiterjedésű hálózatok felügyeletéről szóló szabvány- 
gyűjtemény létrehozását tűzi ki célul. A felügyeleti szabványok: 
"0 Leírják a felügyelt objektumokról szóló információk 
eléréséhez szükséges struktúrákat és konvenciókat. 
-£ Támogatják az információk központosítását, így a külön- 
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féle ügyfelek és felügyeleti eszközök képesek adatokat 
szolgáltatni, visszakeresni és elemezni. 

-? Támogatják, hogy hitelesítés után bárhonnan a háló- 
zatról hozzá lehessen férni a felügyelt objektumokhoz, 
így azok elemezhetők és manipulálhatók. 


A WBEM kialakulása 

A WBEM ajánlást 1996-ban a Microsoft, a Compag Compu- 
ter, a BMC Software, a Cisco Systems és az Intel vezetésé- 
vel több cég hozta létre. Az elképzelés olyan nyílt felügye- 
leti környezet kialakítása volt, melyben a lehető legtöbb 
meglévő technológia és szabvány felhasználásával az 
összes felügyeleti rendszer és alkalmazás elérheti, szabá- 
lyozhatja és megoszthatja egymással és az eszközt 
felügyelő ügynökkel (agent) a felügyeleti információkat. 
Sok szempontból ez a meghatározott cél a World Wide Web 
tapasztalatait vette alapul, ahol az Interneten levő eszkö- 
zök az információk forrásaiként és használóiként anélkül 
szerepelhetnek, hogy tudnák egymásról, hogy a másik mi- 
lyen környezetben működik. A nyílt felügyeleti rendszer 
létrehozásában a webes technológiák és a megszokott 
felügyeleti eszközök együttes használatának lehetősége 
miatt lett a kezdeményezés neve Web-Based Enterprise 
Management (WBEM). 

Az alapító tagok a Distributed Management Task Force-szal 
(DMTF) együttműködve kifejlesztették a bármely felügyele- 
ti eszköz (például SNMP, DMI) definiálását és elérését szol- 
gáló környezetfüggetlen eszközkészlet részletes leírásának 
első verzióját. Ennek fő eleme egy adatleíró eljárás volt, 
amely később - immár a DMTF szabványaként - Common 
Information Model (CIM) néven vált ismertté. 

Az eredetileg HyperMedia Management Schema (HMMS) 
projekt néven futó CIM specifikáció megadta a modellezési 
nyelvet, a névadási és hozzárendelési eljárásokat, melyeket 
az adatszolgáltatóktól és más felügyeleti modellekből szár- 
mazó információk összegyűjtésére és átvitelére használtak. 
A CIM séma szolgáltatja az érvényes modell-leírásokat és az 
információs keretrendszert, megad egy tulajdonságokkal és 
asszociációkkal rendelkező osztálykészletet, ezzel lehetővé 
teszi a felügyelt környezet információinak rendezését. 

A DMTF tulajdonát képezi a CIM specifikációja és a CIM séma, 
melyeket a hálózatfelügyeleti adatok elérésének és megosztá- 
sának iparági szintű szabványaként határoztak meg. 

Az 1996-tól 1998-ig tartó időszakban a Microsoft kidolgoz- 
ta a WBEM Windows-os megvalósítását. Ebbe a munkába 
beletartozott a WBEM szoftverfejlesztő készlet (SDK), a kü- 
lönböző CIM összetevők és CIM-kompatibilis adatszolgálta- 
tók kifejlesztése is. 

1998. júniusában a DMTF bejelentette, hogy átvette a 
WBEM kezdeményezést az alapító vállalatoktól. Jelenleg a 
DMTF a WBEM kezdeményezés megvalósítására irányuló erő- 
feszítések központja, és szervezeti keretet biztosít a WBEM- 
kompatibilis eljárások és szabványok fejlesztésében való 
széleskörű iparági részvételhez. A WBEM-alapú szabványok 
egyedi megvalósítása (például a Microsoft Windows Manage- 
ment Instrumentation SDK (volt WBEM SDK)) továbbra is az 
őket kifejlesztő gyártók feladata. A WBEM kezdeményezés 
átvételekor a DMTF beleegyezett, hogy a meglevő WBEM el- 
járásokat, például a Microsoft CIM megvalósítását referen- 
cia-példaként használja. A DMTF beleegyezett abba is, hogy 
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fenntartja a WBEM ígérte platformfüggetlenséget, és elzár- 
kózik minden megvalósítási függés (például adott program- 
nyelv használata) megadásától bármely követelményben. 


A szabványos WBEM összetevők 
Jelenleg két fő részből áll a WBEM (további szabványok vár- 
hatók, például az XML használata a CIM objektumok plat- 
formfüggetlen megosztására): 
"0 ACIM specifikáció, mely meghatározza a WBEM megva- 
lósítás követelményeit. 
"A CIM séma, mely meghatározza az adattároló tartalmát. 
Alapvetően a WBEM a CIM megvalósítását tűzi ki célul. A CIM 
a felügyelt objektumok objektumorientált sémája. Ezek a felü- 
gyelt objektumok a rendszererőforrások megjelenítési formái, 
és a séma minden általuk szolgáltatott adathoz egyszerű 
adatleíró eljárást nyújt. A WBEM meghatározza, hogyan kell 
az adatokat megjeleníteni, és tartalmaz egy folyamatszab- 
ványt, ami meghatározza az összetevők egymásra hatását. 
A CIM séma a központi (core) modellből, és a közös (com- 
mon) modellekből áll. A központi modell az összes felügye- 
leti tartományra érvényes, a közös modellek különböző 
felügyeleti tartományok (számítógépek, hálózat, adatbázis, 
alkalmazás, egyéb eszközök) közös információit adja meg. 
Maga a séma bővíthető, a bővítő-sémák a közös séma 
technológiafüggő kiegészítései. 


A Microsoft WBEM megvalósítása—a WMI 

A WMI (Microsoft Windows Management Instrumentation — 

Microsoft Windows felügyeleti eszközkészlet) WBEM-kompa- 

tibilis, és CIM alapokon támogatja az egységes rendszer- és 

alkalmazásfelügyeletet. A WMI a Microsoft Windows felügye- 
leti szolgáltatások egyik fő összetevője. A Windows felügye- 
leti szolgáltatások közé tartoznak az Active Directory hely- 
meghatározó és házirend szolgáltatásai, a Microsoft Mana- 

gement Console (MMC) megjelenítési szolgáltatásai, és a 

Windows Scripting Host (WSH) automatizálási képességei is. 

A WMI segítségével csökkenthetők a rendszerek összetevői- 

nek felügyeleti költségei, és a karbantartásukra fordított 

idő. A WMI a következőket biztosítja: 

-? Gazdag és összefüggő információmodellt a Windows 98 
és Windows 2000 működéséről, állapotáról és beállítá- 
sairól (a Windows NT 4.0-hoz és a Windows 95-höz is le- 
tölthetők a WMI fő összetevői) . 

"8 COM API-t, amely egyetlen felületen elérhetővé teszi az 
összes felügyeleti információt. 

"8 Együttműködést más Windows 2000 felügyeleti szolgál- 
tatásokkal. Ez az eszközök gyártóinak egyszerűbbé teszi 
az integrált felügyeleti alkalmazások készítését. 

"8 Rugalmas architektúrát, mely biztosítja a gyártóknak az 
információmodeltl kiterjesztését új eszközökhöz, alkal- 
mazásokhoz, vagy más fejlesztésekhez írt kódmodulok- 
kal (WMI szolgáltatókkal) . 

"8 Részletes eseményarchitektúrát, mely lehetővé teszi a 
felügyeleti információk változásainak azonosítását és 
összesítését, más felügyeleti információkkal való össze- 
hasonlítását és összekapcsolását, valamint a helyi vagy 
távoli felügyeleti alkalmazásokhoz való továbbítását. 

"8 Gazdag lekérdezőnyelvet, mely biztosítja az információs 
modell részletes lekérdezését. 

"8 Scriptelhető API-t, melynek segítségével a felügyeleti 
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alkalmazások fejlesztéséhez használható a Microsoft Vi- 

sual Basic vagy a Windows Scripting Host (WSH). 
A távoli események kezelésének és az információmodell gaz- 
dag lekérdezőnyelvének együttes használata például bizto- 
síthatja az összetett felügyeleti problémák megoldását. Az a 
lehetőség, hogy ezek a megoldások Visual Basic vagy WSH 
parancsfáljok használatával elkészíthetők, új távlatokat 
nyitnak a Windows NT felügyeletéhez. 


A WMI architektúra 

A WBEM három részből álló architektúrával biztosítja a 
felügyeleti adatok összegyűjtését és elosztását. A WMI-ben 
ez az architektúra a szabványos objektum-definíciókból 
(CIM-kompatibilis objektum-tároló), a felügyeleti adatok 
elérésének és elosztásának szabványos protokolljából 
(COM/DCOM; de más protokollok használata is lehetséges) , és 
egy vagy több Win32 WMI adatszolgáltatóként működő dll- 
ből áll. A WMI szolgáltató eszközkészlet adatokat biztosít a 
CIM séma részeinek. 





CIM Objektum kezelő 


Objektumszolgáltatók 


WoM 


WOM kernel 
öbjektumok 


5 A WMI architektúra 














A WMI funkcionalitást biztosító folyamat (process) a 
WinMgmt.exe. Ez a futtatható fájl biztosítja a WMI-t alkotó 
CIM objektumtároló (object repository), CIM objektumkezelő 
(Object Manager) , és API-k működését. 


A CIM objektumkezelő 

A CIM objektumkezelő a Microsoft WBEM megvalósításának 
egyik fő része. A WBEM fő célja az adatok egységes megjelení- 
tése, és azok objektum-orientált módon való beágyazása a CIM 
objektum-tárolóba. A CIM objektumkezelő a tárolóban tárolt, 
felügyelt objektumokhoz gyűjtési és kezelési felületet tartalmaz. 
A CIM objektumkezelő nem éri el közvetlenül az információ- 
kat, hanem a WMI szolgáltatók gyűjtik össze az erőforrástól 
(felügyelt objektumtól) azokat, majd a WMI API-n keresztül 
a felügyeleti alkalmazások számára elérhetővé teszik őket. 


A WMI szolgáltatók 

A WMI szolgáltatók (WMI provider) közvetítőként működnek a 
CIM objektumkezelő, és egy vagy több felügyelt objektum kö- 
zött. Amikor a CIM objektumkezelőtől a felügyeleti alkalma- 
zás egy, a tárolóban nem elérhető információt, vagy általa 
nem támogatott eseményekről szóló értesítéseket kér, továb- 
bítja a kérést a szolgáltatóhoz. Ezután a szolgáltató biztosít- 
ja a kért információt, vagy az eseményről szóló értesítést. 

A WMI az alábbi szolgáltatókat tartalmazza: 

"8 Win32 szolgáltató 
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WDM szolgáltató 

Eseménynapló szolgáltató 

Rendszerleíró adatbázis (registry) szolgáltató 
Teljesítményfigyelő (Performance Counter) szolgáltató 
Active Directory szolgáltató 

Windows Installer szolgáltató 

SNMP szolgáltató 

Más gyártók a WMI SDK alkalmazásával készíthetnek egyedi 
szolgáltatókat, melyek együtt tudnak működni a saját kör- 
nyezetük egyedi felügyelt objektumaival. 

A WMI eljárásai nem a meglévő felügyeleti szabványok (pél- 
dául SNMP, DMI, CMIP) lecserélését szolgálják, és alkalmazá- 
suk nem jelenti a szabadalmazott vagy platformfüggő keret- 
rendszerek (például NDS) kiirtását. A WMI tulajdonképpen 
kiegészíti ezeket azzal, hogy integrációs felületet biztosít, 
melyen keresztül bármely forrásból származó adat elérhető. 


FÁddHPdDPdDBD 


Az események kezelése 

Az eseményekre való figyelmeztetés fontos lehetőség a 
WMI-ben, mert ez biztosítja, hogy az összetevők felderítsék 
a hardverrel vagy szoftverrel kapcsolatos eseményeket 
és/vagy hibákat. Ezután az esemény keresztülhalad a WMI 
architektúrán a megfelelő felügyeleti összetevőhöz, mely 
végrehajthatja a helyesbítő eljárást. 

A WMI-ben az esemény egy történés, amely vagy előre 
megadott, valós világban létrejövő feltételeknek (kívülről jövő 
esemény), vagy a CIM tárolóban bekövetkezett változásoknak 
(belülről jövő esemény) felel meg. Egy esemény megtörténte 
után egy eseményszolgáltató értesíti a CIM objektumkezelőt, 
mely továbbítja az eseményt egy vagy több bejegyzett címzett- 
nek, azaz az eseményfigyelőknek (event consumer). Az ese- 
ményfigyelők bejegyezhetik a CIM objektum-kezelőben, hogy 
adott típusú értesítéseket kapjanak, az eseményszolgáltatók pe- 
dig bejegyezhetők, hogy bizonyosfajta értesítéseket küldjenek. 
Az eseményfigyelők az eseményszolgáltatóktól független műkö- 
dése érdekében a CIM objektumkezelő közvetítőként szerepel, 
megfelelteti egymásnak a bejegyzett figyelőket és a megadott 
szolgáltatókat, és továbbítja a megfelelő eseményeket. 

Az esemény-figyelők anélkül is bejegyezhetik magukat, hogy 
tudnák, mi szolgáltatja az eseményeket és értesítéseket. A 
bejegyzéshez ezek a figyelők egy szűrőt adnak meg, mely a 
WOL (WMI Guery Language — WMI lekérdezőnyelv) használa- 
tával készül el. Ez írja le azokat a feltételeket, melyek létre- 
jöttekor a figyelő értesítést akar kapni. 


A WMI lekérdezőnyelv 

A WOL az SOL olyan , nyelvjárása", mely eseményekről szóló ér- 
tesítéseket, és más WBEM kompatibilis funkciókat támogató 
bővítményeket tartalmaz. Amikor a figyelők bejegyzik magu- 
kat az eseményekről szóló értesítések címzettjeként, tulajdon- 
képpen egy lekérdezést adnak meg, ami leírja az esemény tí- 
pusát és a feltételeket, melyek teljesülésekor értesítést kap- 
nak. A WMI SDK-ban definiált WOL használható értesítésszűrők 
készítésére is. 
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WBEM-kompatibilis scriptprogramozás 
A WMI Script felületei CIM objektumkezelővel együttműködő 
parancsfájl és Visual Basic alkalmazások fejlesztésére hasz- 
nálhatók. A WMI az alábbi nyelvek támogatását biztosítja: 
b Microsoft Visual Basic 
0 Visual Basic for Applications 
0 Visual Basic, Scripting Edition (V8BScript) 
0 Microsoft JScript 
"9 Perl 
A CIM objektumkezelő scriptelési felületei annyiban külön- 
böznek a COM felületektől, hogy ezeket eleve a Visual Ba- 
sic, Visual Basic for Applications, Visual Basic Scripting 
Edition (VBScript) és más parancsnyelvekkel való együtt- 
működésre tervezték. A Microsoft WBEM-kompatibilis 
scriptelés az alábbi előnyöket biztosítja: 
0 Adatközpontú megközelítést alkalmaz, a CIM-et. A CIM 
egy modellt biztosít az eltérő információk kezeléséhez, 
a script API pedig elszigeteli egymástól az alkalmazáso- 
kat, és a különböző adatforrások összetett rendszerét. 
Biztosítja a rendszer-, hálózat-, és alkalmazásinformációk 
széleskörű lefedését. A Microsoft megvalósítás a Win32, 
SNMP, regisztrációs adatbázis, Windows Driver Model 
(WDM), Performance Monitor, eseménynapló, és ADSI szol- 
gáltatókat teszi elérhetővé. Más gyártók, például az Intel, 
a Compag, a Hewlett-Packard és a BMC Software szintén 
fognak készíteni termékeikhez szolgáltatókat, hogy lehető- 
vé tegyék gyártófüggő eszközkészletek használatát (ez így 
lesz a Microsoft Systems Management Serverrel is). A Micro- 
soft egyéb szolgáltatói jelenleg fejlesztés alatt állnak. 
A szolgáltató eszközkészletek könnyen bővíthetők. Az 
eszközök, a minták és a bővíthető szolgáltató architek- 
túra teljes leírása megtalálható a Microsoft WMI SDK- 
ban. Emellett a szolgáltatók fejlesztése széleskörű 
iparági támogatást élvez. 
"0 Egyszerű új parancsfájlokat írni. A Microsoft WBEM- 
kompatibilis API-t egyszerű használni, a séma pedig 
böngészhető és bővíthető. 


b 


V, 


WDM Szolgáltató 

A Microsoft a WDM szolgáltatót az operációs rendszer ker- 

nel kezelésére fejlesztette ki. A WDM eszközkészlet a Win- 

dows Driver Model (WDM) architektúra része, de széleskö- 
rű felhasználhatósága miatt másfajta meghajtóprogramok- 

kal is együtt tud működni (például SCSI és NDIS). A WMI a 

WDM szolgáltatót használja az adatok közzétételére, az 

eszközök beállítására, és az eszközmeghajtók eseményeiről 

szóló értesítések szolgáltatásához. 

A WMI WDM részei az alábbi adatokat osztják szét: 

"0 Közzétett adatok: szabványos adatkészletet találunk a 
Windows 2000-rel szállított meghajtókban. 

8 Egyedi adatok: Az OEM-ek és független gyártók meg- 

"b Biztonsági adatok: A Windows 2000 biztonsági leírói 
szolgáltatják ezeket. 

0 Erőforrásigényes adatok (opcionális): Néhány adat- 
gyűjtő tevékenység jelentősen befolyásolhatja a meghaj- 
tóprogram teljesítményét, ezért ezeket az adatokat csak 
akkor kell gyűjteni, amikor egy felügyeleti alkalmazás kü- 
lön kéri ezt. Amikor az adatokat használó utolsó alkalma- 
zás is befejezi a működést, a WMI jelzi a meghajtóprog- 
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ramnak, hogy fejezze be az adatgyűjtést. Azt, hogy mi az 
erőforrásigényes adat, nem a WMI, hanem a meghajtó 
készítője dönti el, egy egyszerű eljárás segítségével 
Eseményekről szóló értesítések: Az eseményekről 
szóló értesítés a WMI egyik fő funkciója, mert ez teszi 
lehetővé, hogy a meghajtók felderítsék a hardverrel 
kapcsolatos eseményeket és/vagy hibákat. A hardver- 
eseményekről szóló értesítéseket az eseményszűrők és a 
CIM objektumkezelő kezeli. 

A WMI azt is lehetővé teszi, hogy a felügyeleti alkalmazás 
beállításokat végezzen egy eszközön. 


b 


A WMI működés közben - parancsfájl példák 

Nem állítjuk, hogy ezek alapján bárki is képes lesz saját, 
teljes körű rendszerfelügyeleti parancsfájlokat készíteni, 
célunk inkább az, hogy az eddigi elméletet egy kis gyakor- 
lattal támasszuk alá. Tekintettel a CIM objektumok óriási 
számára meg sem próbálunk átfogó képet adni, csupán a 
legkézenfekvőbb objektumok lekérdezésére vállalkozunk. 

A példák kódját egy .vbs kiterjesztésű szövegfájlba írva le- 
het kipróbálni. A futtatás: cscript fájlnév.vbs. Így a kimenet 
a standard out-ra megy, ezáltal könnyen át lehet irányítani 
fájlba a cscript fájlnév.vbs skimenet.txt segítségével. 

Az első példánkban felépítünk egy általános eljárást, ami- 
vel bármelyik WMI osztályt meghívhatjuk és megfigyelhet- 
jük annak összes jellemzőjét. Konkrét alkalmazás esetén 
persze nem kötelező végigmenni minden egyes tulajdonsá- 
gon, elég csak a kiválasztottakat közvetlenül elérni. 

A minden jellemzőt listázó eljárás: 


Sub CallWMI(Provider, Output) 
Set PropSet —— 


GetObject ( "winmgmts : (impersonationLevel-"§— 


"impersonate)") . InstancesOf(Provider) 


For Each Props In PropSet 
For Each Prop In Props.Properties 


Message - Message § Prop.Name 6 " : " 


If IsArray(Prop) Then 
For Each Va In Prop.Value 
If Not IsNull(Va) Then 
Value - CStr(Va) 
Else 
Value - "Null" 
End If 


Message - Message t Value £ "; " 


Next 
Else 

If Not IsNull(Prop.Value) Then 
Value - CStr(Prop.Value) 

Else 
Value - "Null" 

End If 
Message - Message t Value £ "; " 


End If 
Message - Message t vbCrLf 


Next 
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Next 
OutputString - Message 
End Sub 


Az eljárás létrehoz egy példányt a Provider paraméterben 
megadott WMI osztályból, és végiglépked annak összes jel- 
lemzőjén, összegyűjtve azokat szöveges formában az output 
paraméterbe. 

Távoli gép eléréséhez a GetObject-et kell átírni a következő 
módon: 


GetoObject ( "winmgmts : / /gépnév" ) 


Nézzük meg az eljárásunk használatát! 
Alapinformációk lekérése egy számítógépről: 


CallWMI "Win32 ComputerSystem", OutputString 


WScript.Echo OutputString 

A kimenetből néhány érdekesebb sor: 
CreationclassName : Win32 ComputerSystem; 
CurrentTimeZone : 60; 

Description : AT/AT COMPATIBLE; 
Domain : NETACADEMIA; 
DomainRole : 4; 
InfraredSupported : True; 
Name : PLATAN; 
NumberofProcessors : 1; 
SystemStartupDelay : 30; 
SystemType : X86-based PC; 
És még további 100 sor... 


Látható, hogy a Win32 ComputerSystem osztály segítségé- 
vel a legalapvetőbb információkat lehet lekérni egy számí- 
tógépről. Részletesebb információkat további WMI osztályok 
meghívásával lehet elérni. Nézzük meg például, mit lehet 
megtudni a hálózati kártyákról. 

Hálózati kártyák adatainak lekérdezése: 


CAlIWMI "Win32 NetworkAdapter", OutputString 


Kimenet: 

AdapterType : Ethernet 802.3; 

Description : Intel 21041 Based PCI Ethernet 
Adapter; 

MACAddress : 00:80:48:EA:75:8A; 

Manufacturer : Intel; 

PNPDeviceID : PCINVEN 10118DEV OOLl4SSUBSYS 


000000008£REV 11136§61AAA0150558; 


PowerManagementSupported : False; 


Mit lehet tudni a videokártyáról? 


CallWMI " Win32 VideoController", OutputString 
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Kimenet: 


AdapterDACType : S3 SDAC; 
AdapterRAM : 4194304; 
Caption : S3 Inc. Trio3D/2X Display Driver Version 
3.30.10; 
CurrentBitsPerPixel : 24; 
CurrentHorizontalResolution : 1024; 
CurrentRefreshRate : 85; 
CurrentVerticalResolution : 768; 
DriverVersion : 4.1024.330.0010; 
MaxRefreshRate : 85; 
MinRefreshRate : 43; 

. És még további 60 jellemző. 


Ezek a példák csak a hardverrel foglakoztak. Azonban hihe- 
tetlenül sok szoftverinformáció is elérhető a WMI-n keresz- 
tül. Ízelítőül és házi feladat gyanánt a következőket javas- 
lom kipróbálásra: 

Win32 Process 

Win32 Service 

Win32 Share 

Win32 Directory 

Ráadásul ezeken az osztályokon keresztül nemcsak informá- 
ciókat érhetünk el, hanem vannak metódusaik is, amelyeket 
meghívva az adott objektummal kapcsolatos műveleteket is 
el lehet végeztetni. Például a Win32 Directory-nak van 
Compress metódusa, amivel egy kiválasztott állományt vagy 
könyvtárat be lehet állítani tömörítettre. Vagy a Win32. Pro- 
cess-nek van egy Terminate metódusa, amivel egy processzt 
ki lehet lőni. Ha mindehhez hozzávesszük azt a tényt, hogy 
a WMI működik távoli gépre is, akkor valóban fantasztikus 
távvezérlési lehetőség van a kezünkben. 

Megjegyzés: a Wscript.Echo metódus hibaüzenettel elszáll, 
ha a lekérdezés eredménye túl sok szöveget ad vissza. Ez a 
hiba eltűnik, ha a kimenetet fájlba irányítjuk át. 


További információk 

A Windows 2000 Server felügyeleti infrastruktúrájáról szóló 
legfrissebb információk a [1] címen találhatók meg. 

A Windows Management Instrumentation-ről (WMI) bővebb 
információ az MSDN-en a [2] címen lelhető fel. 

WBEM-ről és a DMTF-ről további információk a DMTF webhe- 
lyén találhatók: [3]. 

A Win32-es platformon elérhető osztályokról és azon tulaj- 
donságairól a [4] címről kiindulva lehet részletes segítsé- 
get találni. 


[1] http;, icrosoft.com/windows/server, 
technical/management/default.asp 

[2] http://msdn.microsoft.com/downloads/sdks/ 
wmi/default.asp 

[3] http://www.dmtf.org/ 

[4] http://msdn.microsoft.com/library/psdk/wmisdk/ 
clascomp 3dáj.htm 
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JOGI 


a BSA-val, avagy 
mi 1s az a BSA? 


A 2001. év a szoftverfelhasználók részére érdekes ese- 
ménnyel kezdődött. A Páneurópa Jogász Unió és a BSA (Bu- 
siness Software Alliance) közös rendezésében került sor ja- 
nuár 10.-én egy ,teadélutánra", amelyen tea ugyan nem 
volt, de lehetőség arra igen, hogy megismerkedjünk a titok- 
zatos és rettegett szervezet képviselőivel, munkamódsze- 
reikkel és lehetőségeivel. 

A BSA-ról eddig az óriásplakátokon ábrázolt bilincsbe vert 
kezek, a börtönbe zárt főnökök, a rendőrökkel együtt a cég- 
hez házkutatási paranccsal beállító kommandósok képe je- 
lent meg az illegális, de a legális szoftverfelhasználók kép- 
zetében is. Ugyanakkor sok volt a bizonytalanság, hogy va- 
jon milyen gyártók szoftverjeit vizsgálják, mi a jogkörük, 
mit tehetnek és hogyan? Nos ezekre a kérdésekre - vagy 
ezek közül néhányakra - kaphattak választ azok, akik a tea- 
délutánon jelen voltak. 

A BSA egy - a szoftvergyártók közül néhány által létreho- 
zott - társadalmi szervezet. Mivel a gyártók jelentős része 
(mint pl. a Microsoft) multinacionális cég, így természete- 
sen a BSA is több országban működik, de valamennyi terü- 
leten külön-külön bejegyzéssel létrehozott társadalmi szer- 
vezetként. Vagyis egyesületi formában. Ez azt is jelenti, 
hogy a BSA-nak nincsenek hatósági, pláne nem nyomozati 
jogkörei, így önmagában sem házkutatásra, sem számító- 
gép vagy merevlemez lefoglalására nem jogosult. Ilyen cse- 
lekményeket csak a rendőrség - büntetőeljárás keretében - 
végezhet. Természetesen a rendőrségi eljárásban felkért 
szakértőként közreműködhetnek a BSA szakértők is. 

A BSA csak a tagszervezeteit képviseli. Fellépését a szerzői 
jogi törvénynek arra a passzusára alapíthatja, amely a szer- 
zőt feljogosítja arra, hogy a felhasználótól beszámolót kér- 
jen a szerzői jogvédelem alá eső mű használatáról. Ez ese- 
tünkben azt jelenti, hogy a BSA - mint a Microsoft képvi- 
selője - e szakasz alapján jogosult cégektől információt 
kérni arról, hogy használnak-e Microsoft szoftvert? 

Másik - és a felhasználók szempontjából nem közömbös - 
kérdés, hogy hogyan választják ki azokat a cégeket, ame- 
lyekhez a fenti kérdést intézik? Nos erre is kaptunk választ 
(legalább is részben): a nyilvános adattárakból illetve más 
adatbázisból (ezt nem tudjuk melyikből) kerülnek ki a cél- 
csoportok. Az egyik jól használható adattár a cégbíróságé, 
illetve az Igazságügyi Minisztérium Céginformációs Szolgá- 
latának adatbázisa. A mérlegbeszámolót ugyanis vala- 
mennyi cég köteles e két adatbázisba is leadni. A BSA szak- 
értői szerint pedig e nyilvános adatokból könnyűszerrel 
megállapítható, hogy a nyilvántartott számítástechnikai ál- 
lóeszközök és az ugyancsak a beszámolóban szereplő imma- 
teriális javak (itt kellene a szoftverekre fordított összegnek 
szerepelnie) fedik-e egymást, vagyis megállapítható-e, 
hogy ha az állóeszköz leltárban 20 db. számítógép szerepel, 
akkor az immateriális javak között 20 db. Microsoft Office 
csomag is fellelhető? (Nos az én szerény megjegyzésem, 
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hogy a nyilvános mérlegbeszámoló adatai közül ugyan ki nem 
derül, hogy az állóeszközök hány darab PC-t rejtenek! Tehát 
itt más forrásnak is kell állnia a háttérben!) 

A BSA képviselői nem győzték hangsúlyozni, hogy őket csakis 
az üzleti célú illegális szoftverfelhasználás érdekli, a magán- 
célú nem. E körben kifejezetten elhatárolódtak a korábban 
nagy port felvert esetektől, ahol rendőrségi eljárást indítot- 
tak középiskolás diákok meg nyugdíjas bácsik ellen, akik ott- 
honi gépüket eleve illegális játékprogramokkal feltöltve vásá- 
rolták, és azok jogellenes mivoltáról valószínűleg fogalmuk 
sem volt. A célpontok tehát a cégek. A BSA üzleti célú irány- 
ban próbálja befolyásolni a rendőrségi vizsgálatokat is! 

E program keretében 2000 első félévében 6.000 céget ke- 
restek meg levélben. A levelekben együttműködésre hívták 
fel a cégeket, s kérték, hogy ismertessék, milyen szoftvere- 
ket használnak, és felajánlották, hogy szakértői segítséget 
nyújtanak annak megállapításához, hogy az adott szoftver 
jogszerűen van-e a cég használatában vagy sem. Gondolom, 
hogy sokan erre a kérdésre elmosolyodnak, hiszen úgy vé- 
lik, hogy ez igen könnyen megállapítható: boltban vettem- 
e vagy ismerőstől másoltam, van-e róla számlám, hologra- 
mom, regisztráltattam-e. Nos éppen ez volt az egyik olyan 
kérdés, amelyről a teadélután résztvevői sokáig vitatkoztak. 
A BSA képviselői szerint a szoftver jogosult felhasználását, 
minden kétséget kizáróan a számla bizonyítja. Olyan eset- 
ben, ha a szoftvert eleve a gépre telepítve, a géppel együtt 
vettük, akkor természetesen a számla és az összesítő együtt 
a bizonyíték. Minden más, csak másodlagos bizonyító erő- 
vel bír, így tehát a hologram, a regisztrálás, stb. is. De leg- 
jobb természetesen az, ha minden a rendelkezésemre áll. 
Megjegyzem, hogy az a benyomásom támadt mindezeket hall- 
gatva, hogy a jogban eljárási alapelvként működő bizonyítási 
teher jelen esetben megfordul, legalább is a BSA megközelítése 
szerint. Az eljárási szabályok szerint ugyanis mindig annak kell 
bizonyítania, aki állít, és akinek érdekében áll az állítás valósá- 
gának bizonyítása. Jelen esetben tehát éppen a BSA-nak kelle- 
ne bizonyítania, hogy esetleg nem jogszerűen használom a 
szoftvert, és nem nekem, a felhasználónak kellene a számlákat 
összeszedve, és egyéb dokumentumokat rendszerezve bizonyíta- 
nom a jogszerűséget. E felvetésemre a BSA jogi képviselője az 
alapelvvel egyetértve arra utalt, hogy természetesen a büntető- 
eljárásban a rendőrség bizonyítja a szerzői és szomszédos jogok 
megsértését, vagyis a jogszerűtlen szoftverhasználatot. 
Ugyancsak vitás - még egyes jogászok között is - hogy a 
szerzői jog által szabad felhasználásnak, vagyis a szerző en- 
gedélye és jogdíjfizetés nélküli jogszerű felhasználásnak mi- 
nősül-e, ha a szoftvert csak magáncélú használatra másolják. 
Nos a vita eldőlt, abba az irányba, hogy a szoftver az általá- 
nos elvek alól kivétel. Tehát amíg egy zenei CD saját célú 
hallgatásra történő másolása nem jogellenes cselekedet, 
vagyis a szabad felhasználás körébe tartozik, addig egy já- 
tékszoftver másolása már jogellenes. 
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JOGI ESETEK )b TEADÉLUTÁN A BSA-VAL 
A cikk eddigi részein keresztül a kedves olvasót legjobban bi- 
zonyára az a kérdés izgatta: ha a BSA-nak nincs joga házkuta- 
tást tartani, számítógépet lefoglalni, stb., akkor miért is félünk 
tőle? A válasz egyszerű: a BSA rendkívül jó együttműködést 
épített ki a rendőrséggel. E szervezetnek pedig - alapos gyanú- 
ra indult büntetőeljárás keretében - már minderre van jogköre. 
A kérdés az, hogy mikor és ki ellen indul meg a büntetőel- 
járás. És itt megint aktív szerepe lehet a BSA-nak. Hiszen a 
megkeresett 6.000 cégből azt a 3.000 céget, amelyek nem 
válaszoltak, illetve nem mutattak együttműködést, a BSA 
nem felejti el, és minden bizonnyal komolyabb vizsgálat alá 
vonja őket. Talán éppen úgy, hogy alapos gyanúnak tekin- 
ti az együttműködés megtagadását, és rendőrségi feljelen- 
tést tesz a szerzői és szomszédos jogok megsértése miatt. 
Ez esetben pedig bizton lehet számítani a cikk elején felvá- 
zolt képre: a kommandóra, amelyik házkutatási parancsot 
lobogtatva tör be a céghez és foglal le winchestert vagy 
számítógépet. Újabban ugyan - ha a házkutatás alá vont 
képviselője együttműködik - állítólag már nem viszik el az 
egész gépet, és nem bénítják meg ezzel az egész cég mű- 
ködését, csak egy hitelesített CD-re másolják a tartalmát, 
és azt használják bizonyítékként az eljárásban. 

A BSA jogi képviselője a résztvevőknek még azt a jó taná- 
csot adta, hogy házkutatás esetén felesleges trükközni, fel 
kell tenni a kezet, hogy uraim, most megfogtak, és hívni kell 
az ügyvédet. Nos e jó tanácsok közül a magam részéről csak 
a legutolsóval, az ügyvéd hívásával értek egyet. Beismerni 
felesleges, sőt hátrányos is lehet, hiszen nem biztos, hogy 
bizonyítható a cselekmény elkövetése, és egy jó ügyvéd még 
rengeteg más megoldást alkalmazhat. Ne nehezítsük meg a 
dolgát felesleges beismeréssel! Trükközni pedig szabad, csak 
ne agresszíven, mert a végén tényleg bilincsben viszik el a 
cégvezetőt a felbosszantott rendőrök! 

Nyilván mindenkit izgat még az a kérdés, hogy milyen kö- 
vetkezményekkel számolhat egy ,lebukás" esetén? 

A következmény kettős: büntetés és kártérítés. A büntetés 
kiszabása a bíróság dolga. A Büntető Törvénykönyv szerint 
a cselekmény 8 év szabadságvesztéssel is büntethető. A 
gyakorlatban azonban jellemzően pénzbüntetést alkalmaz- 
nak, de sokszor próbaidőre elhalasztják a büntetés kiszabá- 
sát. A büntetés természetesen függ attól, hogy hány szoft- 
ver vonatkozásában sértették meg a szerzői és szomszédos 
jogokat, milyen értékben stb. Valóban nem a kollegákat 
szeretném reklámozni, de higgyék el nekem, hogy az eny- 
hítő körülmények feltárásában is nagyon sokat tehet egy jó 
ügyvéd! A kártérítés természetesen a szerzői jog jogosult- 
ját illeti meg. A kártérítés összege a szoftver kiskereskedel- 
mi ára, valamint az annak bizonyítható jogosulatlan hasz- 
nálata megkezdésétől számított kamata. 

A BSA természetesen csak a kártérítésben érdekelt, a bün- 
tetőeljárás megindítása csak annak társadalmi elrettentő 
hatása miatt lehet fontos számára. Éppen ezért, ha nem a 
rendőrség nyomozása derít fényt az illegális szoftver hasz- 
nálatra, hanem a BSA, akkor kész megegyezni a kártérítés- 
ben, és eltekinteni a feljelentés megtételétől. 
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Aki biztosra szeretne menni, az követheti a BSA útmutató- 
jában foglaltakat, amelyben tanácsot kap arra is, hogy az 
alkalmazottakkal milyen nyilatkozatot írasson alá, ha mint 
cégvezető, biztosítani akarja magát az alkalmazottak fele- 
lőtlen, rejtve maradó szoftvertelepítgetései ellen. (Megta- 
lálható a BSA weblapján: www.bsa.hu) 
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a A BSA Magyarország honlapja 


Sajnos a jelen cikk terjedelme nem enged teret arra, hogy 
a témát mélyebben ismertessem, így kérem mindazokat, 
akik ennél bővebb információra tartanak igényt, hogy a le- 
galnet levelezőlistán vagy nekem közvetlenül tegyék fel 
kérdéseiket. 
Csatlakozás a levelezési listához: 
1. A csatlakozáshoz írjon egy üres levelet a 

legalnet-join Olyris.pju.hu címre 
2. Csatlakozás után leveleit a 

legalnetOlyris.pju.hu címre írhatja 


Dr. Mayer Erika ügyvéd 


Nádas 8. Mayer Ügyvédi Iroda 
mayer Onadas-mayer.hu 
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hogy további jegyeket 
kapjon az erőforrásokhoz 


A Windows 2000 


biztonsága 
(II. rész) 


A Kerberos és az Active Directory 

Minden Windows 2000 tartományvezérlő az Active Directoryt 
használja címtárként, és tartalmazza a KDC-t. Ez biztosítja 
a felhasználói fiókok információinak egyetlen példányban 
történő tárolását. Nagyobb méretű vállalatoknál szükség le- 
het több tartományvezérlő használatára, de ez nem befolyá- 
solja a Kerberos hitelesítés használatát, mert ahol megtalál- 
ható az Active Directory egy példánya, ott van Kerberos hi- 
telesítési szolgáltatás is. A Kerberos részletes ismertetése a 
következő cikkben található (a 20. oldalon). 


A hitelesítési információk átadása 

Eddig azt az esetet tárgyaltuk, amikor egy ügyfél egyetlen ki- 
szolgálót próbált elérni. Ma már gyakori, hogy egy alkalmazás 
több kiszolgálót használ egy feladat végrehajtása közben 
(például egy webes alkalmazás, amely használja vállalatunk 
web- és adatbázis-kiszolgálóját is). Ahelyett, hogy az ügyfél- 
nek minden egyes kiszolgáló hitelesítési folyamatát végig kel- 
lene csinálnia, a Windows 2000 lehetővé teszi három rétegű 
(multi-tier) alkalmazásokban a hitelesítési információk biz- 
tonságos átadását. 

A már ismertetett több tartományba való egyszeri bejelentke- 
zést a Windows 2000 meghatalmazotti kapcsolatai, és a Ker- 
beros - Active Directory együttműködés teszi lehetővé. Az Ac- 
tive Directoryban egyszer kell elvégezni a megfelelő beállítá- 
sokat, ezután azokat a vállalat összes alkalmazáskiszolgálója 
használhatja. Az ezt támogató eljárást nevezzük a hitelesíté- 
si információk átadásának (delegation of authentication). 


4. Az erőforrás 
rjnrsor rid 


5. A felhasználó 





Alkalmazáskiszolgáló 1 Alkalmazáskiszolgáló 2 


1. A felhasználó 
bejelentkezik wiséev 

és kap egy TGT-t Írectory Server 

a KOC-től 

2. A felhasználó 


bemutatja 
a TGT-t a KDC-nek, 


Key Distribution drag 
Center (KDC) 





Windows Domain Controller 


9 A hitelesítési információk átadása. 


Ahogy az ábrán is látható, az ügyfél átadhatja a hitelesíté- 
si feladatot az alkalmazás kiszolgálásában résztvevő egyik 
kiszolgálónak. A kiszolgáló ilyenkor az ügyfelet személyesí- 
ti meg, és a nevében kér hozzáférést, így az azonosítók és 
jegyek átadása a felhasználó beavatkozása nélkül megy 
végbe. Bár a kiszolgáló megszemélyesíti az ügyfelet, van le- 
hetőség az így végrehajtott műveletek nyomon követésére: 
amikor egy kiszolgáló egy másik kiszolgáló által továbbított 
kérést dolgoz fel, a naplófájljában az ügyfél neve jelenik 
meg, és nem a folyamatban résztvevő másik kiszolgálóé. 
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Ez a modell a Windows 2000 igen fontos része, mert alkal- 
mazásával a biztonság megtartása mellett is megvalósul, és 
egyszerűsödik az egyszeri bejelentkezés. Az Active Directo- 
ryt használó alkalmazásokra való áttéréssel megszüntethet- 
jük vállalatunk hálózatában fellelhető számtalan, biztonsá- 
gi információkat tároló felhasználó-adatbázist, mert az Ac- 
tive Directory biztosítja a biztonsági információk központi 
tárolását, ezzel hálózatunkat könnyebben felügyelhetővé, 
skálázhatóbbá és biztonságosabbá teszi. 


A PKI 

A nyílt kulcsú titkosítást általában nyilvános hálózatokon (In- 
temet) folytatott tevékenységek titkosítására használják. Bizo- 
nyítványokat alkalmaznak az adatok titkosítására, aláírására, 
ügyfelek és kiszolgálók ,személyazonosságának" ellenőrzésére. 
A bizonyítványok használatakor a legnagyobb problémát a bi- 
zonyítványok követése és szétosztása jelenti. A PKI (Public Key 
Infrastructure — nyílt kulcsú infrastruktúra) megoldja a nyílt kul- 
csú bizonyítványok használatának és kezelésének problémáit. 
Ebben a részben a Windows 2000 PKI funkcióit ismertetjük. 

A PKI digitális bizonyítványok, bizonyítvány-kiállító köz- 
pontok (certification authority - CA) és egyéb nyilvántartó 
központok szabványos rendszere, amely ellenőrzi és hitele- 
síti az elektronikus tranzakciókban résztvevő feleket. A PKI 
rengeteg hálózat- és információ-biztonsági igény kielégíté- 
sére használható. Például üzleti partnereinknek ritkán van 
Windows 2000 felhasználói fiókja, de mégis szükség lehet 
személyazonosságuk igazolására, és ezzel együtt erőforrá- 
sainkhoz való hozzáférésük szabályozására. Nos, az ilyen 
felhasználók hitelesítésére szolgál a PKI. 

A nyílt kulcsú bizonyítványok az adatok titkosítására és 
visszafejtésére használt szimmetrikus kulcsok (szimmetri- 
kuszugyanazzal a kulccsal nyílik, mint amivel záródik) érvé- 
nyességének igazolására, és szállítására szolgálnak. A nyílt 
kulcsú kriptográfiában kétféle kulcsot használnak: a nyilvá- 
nos és a titkos kulcsot. A nyílt kulcsokat tartalmazó bizo- 
nyítványok akár az Internetre is feltehetők, sőt, az a cé- 
lunk, hogy lehetőleg minél többen hozzáférjenek - hiszen 
nyilvánosak. A nyílt kulccsal titkosított adatok csak a tit- 
kos kulccsal fejthetők vissza, tehát egy biztonságos 
tranzakció adatainak titkosításához és visszafejtéséhez 
szükségünk lesz a titkos és nyilvános kulcsra is. 

A Windows 2000 PKI biztosítja a nyílt kulcsokon alapuló rend- 
szerek üzembe helyezéséhez és felügyeletéhez szükséges szol- 
gáltatások, protokollok és szabványok keretrendszerét. A Win- 
dows 2000 PKI funkcióinak használatakor a felhasználók és al- 
kalmazások egyszerűen használhatják a bizonyítványokat anél- 
kül, hogy pontosan tudnák, hol is vannak azok tárolva, vagy 
milyen elven működnek. Emellett a PKI teljesen integrált az 
Active Directoryval és a Windows 2000 elosztott biztonsági 
szolgáltatásaival. 
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A Domain Administrator 
beállítja a csoportos 
házirendet 





Az Active Directory. 
Végzi a házirend kiértékelését. 
a bizonyítványok publikálását, (7 
4 felhasználók hitelesítését stb. 






7 EE 


KOC, a bejelentkezés 


rtificate Services: 
során van szerepe 


Ces 
bizonyítvány kiállítás, 
megújítás, visszavonás 





itkezés 
Smart Card segítségével 


5 A Windows 2000 PKI összetevői. 


PKI bizonyítványok támogatása 

A bizonyítvány tulajdonképpen egy digitális tanúsítvány, 
melyet egy CA állít ki, és garantálja a titkos kulcs birtoko- 
sának személyazonosságát. A bizonyítvány összekapcsolja 
a nyílt kulccsal azt a személyt, számítógépet, vagy szolgál- 
tatást, aki a hozzá tartozó titkos kulcsot birtokolja. 

A Windows 2000 szabványos bizonyítványformátuma az 
X.509v3. Egy X.509 bizonyítvány a következőket tartalmaz- 
za: információk arról, akinek a bizonyítványt kibocsátották, 
információk a bizonyítványról, információ a bizonyítványt 
kibocsátó CA-ról (ez utóbbi nem kötelező) . 


Bizonyítványszolgáltatások 

A Windows 2000 tartalmaz egy Active Directoryval és elosz- 
tott biztonsági szolgáltatásokkal integrált Certificate Servi- 
cesnek nevezett szolgáltatást, mely CA-k létrehozására és 
felügyeletére szolgál. 

A CA garantálja és igazolja a bizonyítvány-tulajdonosok sze- 
mélyazonosságát. A CA feladata az érvénytelennek bizonyuló 
bizonyítványok visszavonása, és a bizonyítvány-visszavonási 
listák (certificate revocation list - CRL) közzététele, melyek a bi- 
zonyítványok ellenőrzésére szolgálnak. A legegyszerűbb PKI 
modell csak egy CA-t tartalmaz, de a gyakorlatban a legtöbb 
PKI-t alkalmazó cég több, hierarchiába rendezett CA-t használ. 
A Certificate Services külön összetevője a CA bejegyzési 
weblapjai (enrollment pages). Ezek a weblapok a CA-val 
együtt települnek, és segítségükkel a felhasználók webbön- 
gésző használatával kérhetnek maguknak bizonyítványt. A 
CA weblapok telepíthetők olyan Windows 2000 kiszolgálók- 
ra is, melyeken nincs CA, ebben az esetben a kéréseket egy 
CA-hoz irányítják. A lapok testreszabásához a Windows 
2000-ben található weblapok szolgálhatnak mintául. 

A PKI egyszerű kialakítása érdekében a Windows 2000-t fut- 
tató gépek bizonyítványainak kibocsátása automatikus - 
hisz úgyis az a cél, hogy minél többen ismerjék a publikus 
bizonyítványokat. 


A nyílt kulcs és a házirendek 

A Windows 2000 csoportos házirendjei a bizonyítványok 
számítógépeknek való automatikus kiosztására, a megbíz- 
ható bizonyítványok listáinak és a megbízható CA-k listái- 
nak kialakítására, és a titkosított fájlrendszer adat-visszaál- 
lítási házirendjének kezelésére használhatók. 
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A CryptoAPI 
A Certificate Services mellett a Windows 2000 PKI a Micro- 
soft CryptoAPI version 2-t használja a biztonságos kriptog- 
ráfiai műveletek végrehajtására és a titkos kulcsok kezelé- 
sére. A CryptoAPI egy olyan Windows 2000 API, amely krip- 
tográfiai szolgáltatásokat nyújt a Windows 2000-nek és al- 
kalmazásainak. Olyan funkciókat biztosít, melyek lehetővé 
teszik az alkalmazásoknak az adatok rugalmas titkosítását 
és digitális aláírását, és védik a titkos kulcsokat. A kriptog- 
ráfiai szolgáltatóknak (cryptographic service provider - CSP) 
nevezett független modulok valósítják meg a kriptográfiai 
funkciókat. 
A fejlesztők a CryptoAPI-t a Certificate Services és meglevő 
adatbázisok, vagy harmadik fél által készített címtárszol- 
gáltatások integrálására használhatják. Bizonyítványok 
használhatók a külső felhasználók hitelesítésére. Előfordul- 
hatnak olyan esetek, amikor bizonyos adatainkhoz külső 
felhasználók (például üzleti partnereink) biztonságos hoz- 
záférését kell biztosítanunk. 
A Windows 2000 ezt így valósítja meg: a hozzáférést egy, a 
külső felhasználók számára létrehozott felhasználói fiókkal 
biztosítjuk, melynek a megfelelő jogosultságokat adjuk. 
Minden felhasználónak szüksége lesz személyazonosságá- 
nak igazolásához egy CA által kibocsátott bizonyítványra, 
mely szerepel annak az Active Directory telephelynek, tar- 
tománynak, vagy 0U-nak a megbízható bizonyítványai lis- 
táján, melyben a felhasználót létrehoztuk. Amikor a fel- 
használó bejelentkezik, a rendszer megkeresi a ,bemuta- 
tott" bizonyítványhoz tartozó felhasználói fiókot, és meg- 
határozza, hogy mely adatokat érheti el. A hitelesítési fo- 
lyamat a felhasználó számára észrevétlen. 

Hol használjuk a PKI-t a Windows 2000-ben 

A leggyakoribb PKI-t használó biztonsági funkciók: 

8 Elektronikus levelezés biztonságossá tétele a Secu- 
re/Multipurpose Internet Mail Extensions (S/MIME) 
használatával. 

8 Biztonságos tranzakciók digitális aláírása. 

"8 Biztonságos webes kommunikáció a Secure Sockets 

Layer (SSL) vagy Transport Layer Security (TLS) haszná- 

latával. 

Futtatható kódok aláírása. 

"0 Helyi és távoli hálózati bejelentkezés támogatása. 

"5 Az Internet Protocol security (IPSec) hitelesítés támo- 
gatása azoknál az ügyfeleknél, akik nem használják a 
Kerberos protokollt, és nem megvalósítható az IPSec 
közös titok" hitelesítése sem. 

"2 Fájlok titkosítása a Windows 2000 EFS-sel. 

8 Biztonságos bejelentkezés intelligens kártyákkal. 
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Intelligens kártyák 

A biztonság fokozásának egyre népszerűbb eszközei az in- 
telligens kártyák (smart card) , melyek egyszerű használatuk 
mellett igencsak megnehezítik a hálózathoz való illetékte- 
len hozzáférést. Ezért van a Windows 2000-ben beépített 
intelligens kártya támogatás. 

Az intelligens kártyák többsége úgy néz ki, mint egy bankkár- 
tya. Ezek a kártyák megváltoztathatatlan formában tárolják a 
felhasználók bizonyítványait és titkos kulcsait, így funkcióikat 
(felhasználóhitelesítés, interaktív bejelentkezés, aláírások, biz- 
tonságos levelezés) nagyon biztonságosan látják el. Az intelli- 
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gens kártyán egy chip található, ebben tárolják a felhasználó 

titkos kulcsát, bejelentkezési információkat, és a nyílt kulcsú 

bizonyítványt. A jobb kártyákon elhelyezett chipek kriptográ- 
fiai funkciókat is ellátnak, így biztosítva azt, hogy a titkos 
kulcsnak soha nem kell elhagynia a kártyát. 

Lássuk miért biztonságosabbak az intelligens kártyák a jel- 

szavaknál: 

0 Egy tárgy, a kártya szükséges a felhasználó hitelesíté- 
séhez. 

"0 ArKkártya csak azonosítószámmal (PIN) együtt használ- 
ható, így csak az arra feljogosított személy használhat- 
ja a kártyát. 

"B Megszűnik az azonosítók ellopásának veszélye, mert 
azokat nem lehet lelopni a kártyáról. 

0 ArKkártya nélkül a támadók nem érhetik el az intelligens 
kártyával védett erőforrásokat. 

"0 A jelszavak és újrafelhasználható információk nem 
mennek át a hálózaton. 

A jelszó beírása helyett a felhasználó behelyezi a kártyát a PC- 

hez kapcsolt olvasóba, és beírja a kártya PIN kódját. A Win- 

dows 2000 a kártyán tárolt titkos kulcsot és bizonyítványt 
használja a tartományvezérlő KDC-jén történő hitelesítéshez. 

A felhasználó hitelesítése után a KDC kiadja a TGT-t, innentől 

a hitelesítések a már megismert eljárások alapján történnek. 


Titkosított fájlrendszer 

A Windows 2000 titkosított fájlrendszere (Encrypting File Sys- 
tem - EFS) az asztali és hordozható gépek fájljainak titkosítá- 
sát biztosítja. A gépen tárolt helyi adatok biztonságosabbá té- 
teléhez az EFS lehetővé teszi a számítógépen tárolt, kijelelölt 
fájlok és mappák titkosítását, hogy az arra nem feljogosított 
felhasználók ne olvashassák azokat. Az EFS használata főleg 
olyan számítógépeken hasznos, amelyekhez könnyű fizikailag 
hozzáférni (például laptop) , vagy ellopni. 

Amikor egy NTFS partíció egyik fájlján vagy mappáján enge- 
délyezzük az EFS használatát, az operációs rendszer a nyilvá- 
nos kulcs és a CryptoAPI-n keresztül elérhető szimmetrikus 
titkosítási algoritmusok együttes felhasználásával titkosítja a 
fájlokat. Ez elég egyszerűen végrehajtható: mindössze a File 
Properties párbeszédablakból elérhető Advanced Attributes- 
ban kell egy jelölőnégyzetet kiválasztanunk. (Szorgos olva- 
sóink talán még emlékeznek a novemberi Dupla KV-ban megje- 
lentetett trükkre, mellyel nem csak ezen a módon, hanem a fáj- 
lokon jobb gombbal kattintva is elérhető a titkosítási funkció.) 
Az EFS mentéskor automatikusan titkosítja, megnyitáskor au- 
tomatikusan visszafejti a fájlt. A titkosított fájlt csak az azt 
titkosító felhasználó, és az EFS fájl-visszaállítási bizonyít- 
vánnyal rendelkező rendszergazda képes olvasni. Mivel a tit- 
kosítási eljárás a rendszerbe van építve, működése a felhasz- 
náló számára láthatatlan, feltörni viszont nagyon nehéz. 

Az EFS minden fájl titkosításához egyedi szimmetrikus titkosí- 
tókulcsot használ. A titkosítás után a tulajdonos EFS bizonyít- 
ványából származó nyilvános kulccsal titkosítja a titkosítókul- 
csot is. Mivel csak a tulajdonosnak van meg a titkos kulcs, csak 
ő tudja visszafejteni a titkosítókulcsot, és ezzel együtt a fájlt 
is. A titkosítás még akkor is védi a fájlokat, ha valaki hard- 
verközeli lemezkezelő eszközöket használva próbálja meg- 
nézni az információkat. Ha magát a fájlt el is tudja lopni 
valaki, nem tudja visszafejteni, amíg nem jelentkezik be a 
megfelelő felhasználóként. Mivel nem olvasható a fájl, 
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nem lehet megváltoztatni a tartalmát sem. 

Vészhelyzet, vagy a dolgozó felmondása esetére az EFS tar- 
talmaz egy visszaállítási módszert, mely lehetővé teszi a 
vállalat információinak visszaszerzését. Az EFS használatá- 
nak megkezdésekor a rendszer automatikusan létrehoz egy 
külön visszaállító kulcsot (az eredeti titkosító kulcsot titko- 
sítja a rendszergazda EFS fájlvisszaállító bizonyítványának 
nyilvános kulcsával). A rendszergazda így az EFS fájl- 
visszaállító bizonyítvány titkos kulcsa segítségével vissza- 
fejtheti a titkosított fájlt. 


Biztonsági beállítási minták 

A hálózat biztonsági beállításainak egyszerűbb elvégzéséhez és 
felügyeletéhez használható a Windows 2000 biztonsági minták 
(Security Templates) eszköze. Ez az MMC beépülő modul szabvá- 
nyos minták létrehozását, és azok egységes érvényesítését teszi 
lehetővé több felhasználó, vagy számítógép beállításaiban. 
Maga a biztonsági minta egy olyan fájl, melyben a bizton- 
sági beállítások egy csoportja tárolható. A Windows 2000 
tartalmaz beépített biztonsági mintákat, melyek a számí- 
tógép szerepének megfelelően kevésbé, vagy nagyon biz- 
tonságos beállításokat tartalmaznak. Ezek a minták hasz- 
nálhatók eredeti formájukban, de sokat segíthetnek egye- 
di biztonsági beállítás létrehozásában is. 

A Security Configuration and Analysis eszköz a Security 
Templates beépülő modul kiegészítője, mely a biztonsági 
mintákban megadott tiltások érvényesítését, a biztonsági 
beállítások elemzését, és az aktuális beállítások mintákkal 
való összevetését biztosítja. Segítségével megállapíthatjuk, 
hogy a számítógépek megfelelnek-e a vállalat szabványainak. 


Biztonságos hálózatok - IPSec 

A hálózaton utazó adatok védelmére a Windows 2000 az In- 

ternet Protocol security-t (IPSec) használja. Az IPSec egy 

szabványos protokollkészlet, mely a nem biztonságos háló- 

zaton folytatott biztonságos, titkosított kommunikációt 

biztosítja. A titkosítás az IP hálózati rétegben történik, így 

a legtöbb alkalmazás számára láthatatlan. Az IPSec vég- 

ponttól-végpontig biztosítja a biztonságos átvitelt, tehát 

ha a küldő titkosítja az IP csomagokat, csak ő képes vissza- 

fejteni azokat, útközben pedig a csomagok olvashatatlanok 

(Illetve olvashatók, nyugodtan meg lehet nézni a Network 

Monitorral. Sok sikert kívánunk a visszafejtéshez! :) ). 

Az IPSec az alábbi biztonsági funkciók ellátására képes: 

"8 Kerberos hitelesítés, bizonyítvány, vagy ,közös titok" 
(jelszó) alapján azonosítja az IP adatcsomagok küldő- 
jét 

"b Biztosítja a hálózaton átmenő IP adatcsomagok sértet- 
lenségét 

"0 Titkosítja a hálózaton átmenő összes adatot 

"0 Elrejti a küldő IP címét a ,kíváncsiskodók" elől 

Ezek a funkciók biztosítják, hogy a hálózaton átmenő adatok 

útközben nem változtathatók meg, és azokat illetéktelen sze- 

mély nem tudja lehallgatni, megnézni, vagy másolni. 

A többi biztonsági házirendhez hasonlóan az IPSec háziren- 

dek is számítógép, vagy tartomány szintjén érvényesíthetők. 
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Bővíthető architektúra 
A meglévő ügyfelekkel való együttműködéshez, és a speciá- 
lis biztonsági eljárások kihasználásának biztosítására a Win- 
dows 2000 többféle biztonsági protokollt támogat. Az ope- 
rációs rendszer ezen összetevője a Security Support Provider 
Interface (SSPI, kb. biztonság-támogató felület). Ez olyan 
Windows 32 API, melynek segítségével az alkalmazások és 
rendszerszolgáltatások (például az Internet Explorer és az 
IIS) használhatják a biztonsági eljárásokat, de elrejti azok 
összetevőit az alkalmazások elől. Az SSPI biztosítja a Win- 
dows biztonsági környezet egységesítését. Az alábbi ábrán 
látható az SSPI összetevők közti elhelyezkedése 
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0 Az SSPI összekapcsolja az alkalmazásprotokollokat 
a biztonsági protokollokkal. 


Az SSPI segítségével az alkalmazásfejlesztők Windows 2000 
biztonsági protokollokat használó alkalmazásokat készíthet- 
nek. Az SSPI olyan felületet biztosít, mely képes hitelesített 
kapcsolatok létrehozására. Az SSPI köztes folyamatként mű- 
ködik, maga a hitelesítési eljárás az alkalmazás elől rejtve 
marad, ezért többféle security support provider (SSP, bizton- 
ság-támogató) közül lehet választani anélkül, hogy foglal- 
kozni kéne a kompatibilitási problémákkal. Például a Kerbe- 
ros és NTLM hitelesítések a Windows 2000 SSP-i, ezért az 
SSPI-hez írt alkalmazások az ügyfél és kiszolgáló beállításai 
alapján ezek bármelyikét használhatják hitelesítésre. 


Együttműködés 

A Windows 2000 a szabványos, több operációs rendszeren 

is megvalósított Kerberos protokollt használja, ezért létre- 

hozhatók Windows 2000 és más platformok Kerberos meg- 
valósításait integráló heterogén rendszerek. Ez teszi lehe- 
tővé a Windows 2000 és más operációs rendszerek bizton- 
sági infrastruktúrájának integrálását, vagyis például UNIX- 
ot futtató ügyfelek bejelentkezhetnek a Windows 2000 ki- 
szolgálóra, és Windows 2000 ügyfelek bejelentkezhetnek 

UNIX kiszolgálóra - Kerberos hitelesítést használva. UNIX- 

os és Windows 2000 tartományok között megbízotti kap- 

csolatok is létrehozhatók. 

Az ilyen rendszereknek három fő eleme van: 

"8 A Kerberos ügyfél, ami a Kerberos szolgáltatásoknál hi- 
telesíti a felhasználókat. 

8 A Kerberos KDC, ami hitelesítési szolgáltatást végez a 
tartomány angolul realm, a Windows 2000 terminológiá- 
ban a tartomány angolul domain. Esetünkben ezek egy- 
más megfelelői) 

"0 Az elérés módja, és a hitelesítést igénylő hálózati erő- 
források 
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Naplózás 

Nem elég kiépíteni egy biztonsági infrastruktúrát, meg kell 
győződnünk arról is, hogy az megfelelően működik, ezért 
fontosak a biztonság területén az auditálási szolgáltatások. 
Az objektumok létrehozásának és módosításának megfigye- 
lése lehetővé teszi a felmerülő biztonsági problémák 
megértését, a felhasználók felelősségre vonását és bizonyí- 
tékul szolgál a biztonsági szabályok megsértésekor. 

Ennek elősegítésére a Windows 2000 biztonsági auditáló 
eszközöket tartalmaz, melyek lehetővé teszik a biztonság- 
gal kapcsolatos események (például sikertelen bejelentkezé- 
si kísérletek) megfigyelését. Ezzel könnyebben felderíthető- 
vé válnak a behatolási és adatlopási kísérletek. A Windows 
2000 auditálási funkciói sokkal részletesebbek, mint a Win- 
dows NT 4.0-éi. 

A leggyakrabban auditált eseménytípusok: 

6 Objektumok (például fájlok és mappák) elérése 

"8 A felhasználói és csoportfiókok kezelése 

"6 Felhasználók be- és kijelentkezése 

Az auditált eseményeket a Windows 2000 biztonsági ese- 
mény-naplójában lehet megtekinteni. 


További információ 

A cikkünkben bemutatott témakörökről bővebb információ- 
val szolgáló dokumentumok az alábbi helyeken érhetők el 
(a hivatkozásokat témakörök szerint csoportosítottuk) : 


http: mi. i 2 
§ Ti 0 
http: .microsoft.com/wind. 

Active Directory: 
http://www.microsoft.com/windows2000/library/ 


windowsnt 
52000/Libri 


hn i ir f 
http://www.micrt m/win 2 libri 
howitworil ivedi 
K 55 ZEZIENT üttműködés: 

§ icri indows2000/libra 

3 i indows2000/libri 
IPSec: 
http: .micro: com/windows2000/librai 

hnologi 1 fa 
PKI: 
http: micri .com/win 2 ibr 

annin ri ki. 
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Kerberos 


A Kerberos Version 5 a Windows 2000 új hitelesítési proto- 
kollja. A protokoll önmaga egyáltalán nem új, immár több 
mint egy évtizednyi fejlesztés eredménye. Ebben a cikkben 
áttekintjük a Kerberos alapjait, használatának előnyeit, va- 
lamint azt, hogy miképp használja a Windows 2000 a Ker- 
beros-t mint hitelesítő protokollt. 


Hitelesítés a Windows 2000-ben 

A Windows 2000 rendszer erőforrásainak eléréséhez a fel- 

használónak hitelt érdemlően azonosítania kell önmagát. 

Ez az azonosítás általában a rendszerbe való belépéskor tör- 

ténik meg, ezután a felhasználó egy testre szabott , access 

token"-t kap, ami tartalmazza jogosultságait, csoporttagsá- 
gát, stb. A szolgáltatást nyújtó eszközök ezt az access to- 
kent ellenőrzik, majd ez alapján döntik el, hogy a felhasz- 
náló hozzáférhet-e egy erőforráshoz (megosztott fájlhoz, 
számítógéphez, stb.), vagy sem. A Windows 2000 hálózati 

(tehát nem telefonos) kapcsolaton keresztül felhasználóit 

két protokoll segítségével hitelesítheti: 

b Kerberos Version 5 - A Windows 2000-t használó számí- 
tógépek között Windows 2000 tartományban alapértel- 
mezett hitelesítési protokoll. 

B. Windows NT LAN Manager (NTLM) - Az NTLM a Windows 
NT 4.0 alapértelmezett hitelesítési protokollja volt, a 
Windows 2000 elsősorban kompatibilitási okokból tartal- 
mazza. A különálló, nem tartományi tag (stand alone) 
Windows 2000 operációs rendszer - később látni fogjuk, 
hogy nyilvánvaló okokból - is NTLM hitelesítést használ. 

A Windows régebbi verziói (Windows 3.11, Windows 9x, Win- 

dows NT 4.0) az NTLM (illetve LanMan) hitelesítést fogják 

használni a Windows 2000-hez való csatlakozáskor. Ugyan- 
csak NTLM hitelesítést használ a Windows 2000 is, amikor 

Windows NT 4.0 számítógép vagy tartomány erőforrásaihoz 

szeretne hozzáférni. Ha azonban a Windows 2000-nek lehe- 

tősége van választani, választása minden lehetséges eset- 
ben a Kerberos Version 5 protokoll lesz. 


A Kerberos hitelesítés előnyei 

Vajon miért ragaszkodik a Windows 2000 ennyire a Kerberos 
protokollhoz? Az NTLM hitelesítésnek köztudottan több hát- 
ránya van: egyrészt, a kapcsolatfelvétel során a felhasználó 
jelszavából létrehozott , kivonat" (hash) többször megjelenik 
a hálózaton - ez bizonyítottan nem igazán biztonságos -, 
másrészt pedig a tartományok közötti hitelesítés folyamata 
kettőnél több tartomány esetén olyannyira elbonyolódik, 
hogy gyakorlatilag nem is lehetséges. Érthető tehát a szak- 
emberek és a Windows 2000 fejlesztőinek törekvése: nem 
elég, hogy egy új, biztonságosabb, hatékonyabb hitelesítési 
protokollra van szükség, de lehetővé kell tenni, hogy ez a 
protokoll teljes Windows 2000 környezetben 1009-ig kivált- 
hassa az NTLM hitelesítést. 

A Kerberos használata ezenkívül számos további előnnyel jár: 
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Gyorsabb kapcsolat - NTLM esetében a kiszolgáló (akihez az 
ügyfél fordult) a tartományvezérlő segítségével hitelesítette 
az ügyfelet (ez volt a , pass through"). A Kerberos használa- 
tával a kiszolgáló önmaga hitelesítheti az ügyfelet, nincs 
szükség a tartományvezérlő közbenjárására, így csökken a 
hálózat terhelése. Ezen kívül - az NTLM-mel ellentétben - 
elég, ha az ügyfél egyszer beszerzi az adott kiszolgálóhoz 
szükséges hozzáférési lehetőséget, amit a kapcsolat további 
részében igény szerint akár többször is felhasználhat. 
Kölcsönös hitelesítés - Az NTLM-et alkalmazó rendszerek- 
ben a kiszolgáló azonosította az ügyfelet, az ügyfél (vagy 
akár egy másik kiszolgáló) azonban nem lehetett biztos ab- 
ban, hogy a kiszolgáló valóban az, akinek azt ő hiszi. A Ker- 
beros protokoll ilyen értelemben nem tesz különbséget: ki- 
szolgálónak számít mindenki, aki egy szolgáltatást mások 
által elérhetővé tesz, és ügyfél mindenki, aki egy ilyen szol- 
gáltatáshoz szeretne hozzáférni. A Kerberos hitelesítés 
mindkét résztvevője biztos lehet abban, hogy a kapcsolat 
másik végén az található, akinek az mondja magát. 
Meghatalmazásos hitelesítés - A Windows szolgáltatások, 
miközben egy ügyfél nevében tevékenykednek, egyfajta 
,megszemélyesítést" alkalmaznak, így a szolgáltatásnak min- 
denhez pontosan annyi joga van, mint a hozzá kapcsolódó 
ügyfélnek. A helyi számítógépen belüli ilyen megszemélyesí- 
téseket mind az NTLM, mind a Kerberos lehetővé teszi. Csak 
a Kerberos képes viszont a ,megszemélyesítés" jellegű hite- 
lesítésre, amire a mai, háromrétegű alkalmazások esetén sok- 
szor szükség van - nevezetesen, hogy az alkalmazás középső 
rétegén található kiszolgáló az alsó réteg kiszolgálójával 
(például egy adatbázis-kiszolgálóval) az ügyfél nevében és az 
ő jogaival felruházva tartja a kapcsolatot. Az NTLM nem tá- 
mogatja a hasonló megoldásokat. 

A tartományok közötti megbízotti kapcsolatok kezelése 
egyszerűbb - a kölcsönös hitelesítésnek köszönhető, hogy 
a Windows 2000 tartományok kapcsolatai alapértelmezés- 
ben kétirányúak és tranzitívak (tranzitív: ha A tartomány 
megbízotti viszonyban áll B tartománnyal, B pedig C-vel, ak- 
kor A automatikusan megbízotti viszonyba kerül C-vel is). 
A Windows 2000 tartományi fába rendezett tartományok 
kapcsolatai sokkal egyszerűbbek és átláthatók. A fa bármely 
tartománya, illetve tartományi erdő esetén az erdő bármely 
fájának bármely tartománya által kiadott hitelesítés az 
adott fában illetve erdőben érvényes. 

Együttműködés - A Windows 2000 Kerberos implementáció- 
ja az Internet Engineering Task Force (IETF) által ajánlott 
szabványokon alapul. A szabványos megvalósítás jó alapot 
teremt más, ugyancsak Kerberos Version 5 hitelesítési pro- 
tokollt használó rendszerekkel való együttműködésre. 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
2001. 02. 


20 





2 


WINDOWS 2000 0) KERBEROS 

Kerberos hitelesítési protokoll szabványai 

A Kerberos hitelesítési protokollt a Massachusetts Institute 
of Technology (MIT) szakemberei az úgynevezett , Project 
Athena" projekt keretében már több, mint tíz éve fejlesz- 
tik. A protokoll első nyilvános változata már a negyedik 
verzió volt. A vá áttekintése és széles körű felhasználása 
során összegyűlt tapasztalatok alapján fejlesztették ki a je- 
lenlegi, ötödik verziót, amely jelenleg szabványjavaslatként 
található meg. A Windows 2000 Kerberos az RFC1510 imp- 
lementációja, a Kerberos segítségével átadott biztonsági 
erőforrásokhoz) pedig az RFC1964 Internet szabványjavasla- 
tot (GSS API) követik. 


A Kerberos bővítményei 

A Kerberos protokoll alapvetően szimmetrikus (közös kulcsú) 
titkosítási algoritmuson alapul, ezért a Windows 2000 az ere- 
deti Kerberos protokoll kibővített változatát használja. Termé- 
szetesen ez a bővítmény is egy IETF szabványtervezet megva- 
lósítása. Ez teszi lehetővé, hogy a Kerberos hitelesítési folya- 
mat korai szakaszában kihasználhassuk az aktív memóriakártya 
(smart card") és egyéb nyílt kulcsú infrastruktúrák előnyeit. 
A Kerberos és a nyílt kulcsú hitelesítés kapcsolatáról részlete- 
sebben a cikk második felében ejtünk szót. 


A protokoll áttekintése 

A Kerberos hitelesítő protokoll egy kommunikációs kapcsolat 
résztvevőinek kölcsönös azonosítását teszi lehetővé olyan kör- 
nyezetben, ahol az átvitt adat illetéktelenek által látható, mó- 
dosítható, egyszóval a biztonságos adatátvitel nem garantál- 
ható. Ez a környezet - természetesen - nagyon hasonlít nap- 
jaink Internetéhez, ahol az illetéktelen behatoló átveheti akár 
az ügyfél, akár a kiszolgáló szerepét, és így értékes informá- 
ciókhoz juthat. Feladatunk tehát egy olyan biztonságos kom- 
munikáció megvalósítása, amely az első kapcsolatfelvételtől 
kezdve kizárja az illetéktelen hozzáférést. 


Alapok - avagy legyen egy közös titkunk 

A Kerberos protokoll alapja a közös titkon alapuló hitelesítés. 
Az elv egyszerű: ha egy titkot csak két ember ismer, azok a kö- 
zös titok segítségével könnyedén azonosíthatják egymást. 
Vegyük példaként az angolszász világban oly népszerű párost, 
Alicet és Bobot. Tegyük fel, hogy Alice gyakran küld üzenete- 
ket Bobnak, Bob viszont szeretne biztos lenni abban, hogy az 
Alice-tól kapott leveleket valóban Alice írta. Elhatározzák, 
hogy együtt választanak egy jelszót, amit nem árulnak el ket- 
tőjükön kívül senkinek. Ha Alice üzenetén valahogy látszik, 
hogy Alice ismeri a közös titkot, Bob biztos lehet abban, hogy 
a levél valóban Alicetől származik. 

Adódik azonban egy probléma: honnan derül ki, hogy Alice va- 
lóban ismeri a titkot? Ha Alice beleírná azt az üzenetbe, akkor 
a nevető harmadik, a kis gonosz Carol elég, ha csak egy ilyen 
üzenetet elkap a hálózaton, a titok máris nem titok többé. Va- 
lami más megoldásra van szükség: anélkül kell jeleznünk a jel- 
szó ismeretét, hogy azt beleírnánk az üzenetbe. 

A Kerberos ezt közös kulcsú (más néven titkos kulcsú, vagy 
szimmetrikus) titkosítás segítségével oldja meg. A szimmet- 
rikus titkosítás lényege, hogy egy adott, közös kulcs segít- 
ségével titkosított üzenetet ugyanazzal a kulccsal tudunk 
csak megfejteni. A kommunikáció résztvevői pedig ezt a 
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kulcsot használják közös titokként. A titok ismerete egysze- 
rűen bizonyítható: egyik részről az üzenet titkosítása, má- 
sik részről a megfejtése a bizonyíték, hiszen a közös kulcs 
ismerete nélkül ezek egyike sem lehetséges. 


Hitelesítők (authenticators) 

Vegyünk egy egyszerű, titkos kulcson alapuló hitelesítési 

protokollt. A kapcsolatfelvétel elején valaki áll a virtuális 

ajtó előtt és bebocsátást kér. A belépéshez egy, a közös 
kulccsal titkosított adatcsomagot, úgynevezett hitelesítőt 
nyújt át. Az adatcsomag eredeti tartalmának minden eset- 
ben másnak kell lennie, különben a hálózaton elkapott hi- 
telesítőt később bárki illetéktelenül felhasználhatná. 

A kapu őre átveszi a hitelesítőt, majd az általa ismert tit- 

kos kulccsal megpróbálja megfejteni. Ha ez sikerült, az őr 

biztos lehet abban, hogy az ajtó előtt kívül olyasvalaki áll, 
aki ismeri a közös kulcsot. (Márpedig azt csak ketten isme- 
rik: az őr és a belépésre jogosult felhasználó.) 

Ha a hitelesítés kölcsönös, az őrnek is hitelesítenie kell önma- 

gát a felhasználó előtt. A teljes üzenetet nem küldheti vissza, 

hiszen azt a kulcs ismerete nélkül is bárki megtehetné. Inkább 

a megfejtett üzenet tartalmát valahogy megváltoztatja, majd a 

módosított adatcsomagot titkosítja, és hitelesítőként visszaad- 

ja az ajtó előtt álló idegennek. Az a saját kulcsával megfejti az 
üzenetet, ellenőrzi a tartalmát, és ha mindent rendben talált, 
biztos lehet abban, hogy az ajtónálló is rendelkezik a megfele- 
lő kulccsal: hiszen képes volt megfejteni az üzenetet, megvál- 

toztatni a tartalmát, majd titkosítva visszaküldeni azt. Ebben a 

pillanatban az őr és az idegen azonosították egymást. 

Lássuk ugyanezt kicsit részletesebben, Alice és Bob példá- 

ján. Alice a felhasználó, aki szeretne hozzáférni Bob egy 

szolgáltatásához. 

1. Alice egy üzenetet küld Bobnak, amely a saját nevéből, va- 
lamint egy, a közös kulccsal titkosított hitelesítőből áll. 
Ebben a példában a hitelesítő két adatmezőt tartalmaz: az 
egyik valami, ami azonosítja Alicet, mondjuk a neve; a 
másik pedig az Alice számítógépén mért pontos idő. 

2. Bob megkapja Alice üzenetét. Az üzenetből azonnal lát- 
szik, hogy olyasvalaki küldte, aki Alicenak mondja ma- 
gát. Bob a közös kulccsal megfejti a hitelesítőt, és így 
hozzáfér Alice valódi nevéhez, valamint az Alice számí- 
tógépén mért időhöz. A protokoll működéséhez fontos, 
hogy Bob és Alice számítógépének órái szinkronizálva 
legyenek. Tegyük fel, hogy a két óra közötti eltérés so- 
ha nem nagyobb, mint öt perc. Bob tehát összehason- 
lítja a hitelesítőben kapott időt és a saját óráját. Ha az 
eltérés kevesebb, mint öt perc, Bob majdnem biztos le- 
het abban, hogy az üzenetet Alice küldte. Azért csak 
majdnem, mert lehetséges, hogy Alice hitelesítőjét va- 
laki a hálózaton elkapta, majd változatlanul, de öt per- 
cen belül újrakülte. Ez a megismételt hitelesítő a fentiek 
alapján még érvényesnek számítana. Bob ezt úgy kerül- 
heti el, hogy megjegyzi az Alicetől utoljára megérkezett 
hitelesítő időpontját, és ha annál régebbi, vagy azzal 
megegyező időpontú hitelesítőt kap, legalábbis gyana- 
kodni kezd. Ha azonban minden rendben van, immár 
biztos lehet abban, hogy az üzenet Alicetől érkezett. 

3. Most Bobon a sor: kiveszi az időpontot az Alicetől kapott 
hitelesítőből, azt a közös kulccsal újra titkosítja, majd 
visszaküldi Alicenek. 
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Figyeljük meg, hogy Bob nem a teljes hitelesítőt küldte 
vissza - hiszen arra bárki képes lenne -, hanem annak csak egy 
részét. Alice így biztos lehet abban, hogy Bob rendelkezik a 
közös kulcs egy példányával, hiszen képes volt megfejteni az 
üzenetet, módosítani a tartalmát, majd újra titkosítani azt. 
Alice megkapja Bob üzenetét, visszafejti a titkosított ada- 
tokat, majd a kapott időpontot összehasonlítja az ő általa 
küldött adattal. Ha a két időpont megegyezik, akkor Alice 
biztos lehet benne, hogy üzenetét Bob kapta meg, hiszen 
a közös kulcsot csak ők ketten ismerik. 


Hitelesítő 


Szia itt Alice! K.a(Alice, idő) 





Hitelesítő 


Kafidőj 


Alice e 


5 Alice és Bob kölcsönös azonosítása (Kg a közös kulcs, 
Kaetfadat) a közös kulccsal titkosított adat jele ) 


Központosított kulcskezelés (Key Distribution) 

Ez azonban még korántsem jelent megoldást minden prob- 
lémára. Mindenekelőtt feltételezzük, hogy Alice és Bob 
előzőleg valamilyen biztonságos csatornán (mondjuk, fül- 
besúgással) megegyeztek a közös titokban. A számítógé- 
pek azonban viszonylag ritkán sugdosnak egymás fülébe, 
másrészt pedig ha nem kettő, hanem mondjuk nyolc egyed 
szeretne biztonságosan kommunikálni, bizony nagy lenne 
a sugdolózás. A súgás problémáját egyelőre hagyjuk el, te- 
gyük fel, hogy van mód arra, hogy biztonságosan megálla- 
podhassunk a közös kulcsban. A bábeli zűrzavart pedig úgy 
kerülhetjük el, ha kijelölünk egy központi egyedet, akinek 
mindenki megsúgja a saját kulcsát, és ha valaki kommuni- 
kálni szeretne, ugyancsak tőle kéri el a címzettnek szóló 
kulcsot. Az alábbi ábrán jól látszik, hogy mennyivel kisebb 
lesz a hangzavar. 
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5 A központosított kulcskezelés lényegesen kevesebb 
kapcsolatot igényel 


Itt jön a képbe a görög mitológiából Kerberos (pontosabban 
Cerberus) , Hádes - az alvilág kapuját örző - háromfejű kutyá- 
ja. A modern Kerberos három feje a következő: az ügyfél, aki 
a szolgáltatást igénybe szeretné venni; a kiszolgáló, aki a 
szolgáltatást nyújtja; valamint a harmadik fél, aki segít ab- 
ban, hogy az ügyfél és a kiszolgáló végül egymásra találjon. 
Ez a harmadik fél, mint a fenti ábrán is látszik, a Key Distri- 
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WINDows 2000 KERBEROS 
bution Center (KDC). A KDC egy megbízható, biztonságos ki- 
szolgálón fut, ő kezeli a Kerberos tartomány (realm) bizton- 
sági adatbázisát. A Kerberos tartomány egyébként egyenran- 
gú a Windows 2000 tartománnyal (domain), tehát minden 
Windows 2000 tartományban található legalább egy, a helyi 
feladatokkal foglalkozó KDC. A KDC és az ügyfél egymás köz- 
ti kommunikációjuk során az ügyfél úgynevezett hosszú távú 
kulcsát (long-term key) használják, amit előzőleg általában a 
felhasználó jelszavából állítanak elő. A KDC természetesen a 
tartomány minden felhasználójának és számítógépének is- 
meri a hosszú távú kulcsát. 

Ha tehát egy ügyfél szeretné felvenni a kapcsolatot egy ki- 
szolgálóval, előbb szól a KDC-nek, aki az ügyfél és a kiszol- 
gáló jövőbeli kapcsolatára egy eldobható, úgynevezett rövid 
távú kulcs (session key) formájában áldását adja. Minden új 
ügyfél-kiszolgáló kapcsolathoz új rövid távú, más néven sza- 
kaszkulcs tartozik. A KDC ezt a rövid távú kulcsot az ügyfél 
hosszú távú kulcsával titkosítva elküldi az ügyfélnek; a ki- 
szolgáló hosszú távú kulcsával titkosítva elküldi a kiszolgá- 
lónak, azok megfejtik az üzenetet és az új, közös szakasz- 
kulcs segítségével máris indulhat a társalgás. 

Azaz csak indulhatna, de mi történik, ha a KDC csomagja a ki- 
szolgálóhoz valamilyen okból nem jut el? Az ügyfél hiába ko- 
pogtat a kiszolgálónál, süket fülekre talál. Ha az ügyfélhez 
nem jut el a kulcs, a kiszolgáló várna hiába, és számítástech- 
nikai körökben - mint tudjuk - még a várakozás sincs ingyen. 


Szakaszkulcsok (Session Tickets) 

A való világban ez kicsit másként működik. A szakaszkulcsot 
a KDC csak az ügyfélnek küldi el, mégpedig úgy, hogy a 
visszaküldött szeretetcsomagba - az ügyfél hosszú távú kul- 
csával titkosított szakaszkulcs mellé - beletesz egy, a kiszol- 
gáló számára titkosított adatstruktúrát, amely a szakaszkulcs 
mellett még más hasznos információkat is tartalmaz (amit 
persze az ügyfél se visszafejteni, se módosítani nem képes). 


Szeretnék beszélni , B"-vel 
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5 A KDC működés közben (KA az ügyfél, Kg a kiszolgá- 
ló hosszú távú kulcsa, S,g a KDC által a jövendő kapcso- 
lathoz generált szakaszkulcs) 


Ezt a beágyazott adatcsomagot hívjuk szakaszjegynek (sessi- 
on ticket) , mégpedig azért, mert az ügyfél ezt a jegyet bemu- 
tatva tudja majd felvenni a kapcsolatot a kiszolgálóval. A KDC 
nem foglalkozik azzal, hogy az üzenetek valóban eljutnak-e a 
címzetthez, ugyanis semmi baj nem történik, ha a válasz el- 
veszik - legfeljebb az ügyfél később újabb kulcsot kér. 

Lássuk, mihez kezd az ügyfél a visszakapott csomaggal. 
Egyrészt, a saját hosszú távú kulcsával kicsomagolja a sza- 
kaszkulcsot, és biztonságos helyre teszi. A szakaszjegyet a 
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kulcs mellé helyezi. Amikor a konkrét kapcsolatfelvételre 
sor kerül, a szakaszkulccsal előállít egy hitelesítőt (authen- 
ticatort), majd ezt és a címzetthez érvényes szakaszjegyet 
elküldi a kiszolgálónak. A kiszolgáló a csomagból kiveszi a 
neki szóló szakaszjegyet, a saját hosszú távú kulcsával 
megfejti azt, kiveszi belőle a szakaszkulcsot és jegy egyéb 
adatait. Ha az adatok alapján úgy dönt, hogy szóba áll az 
ügyféllel, a szakaszkulcs segítségével kicsomagolja a kapott 
hitelesítőt, ellenőrzi az időt, törli a hitelesítő egy részét, a 
maradékot a szakaszkulccsal visszacsomagolja, és visszakül- 
di az ügyfélnek. Az ügyfél a visszakapott hitelesítőt vissza- 
fejti, ellenőrzi a tartalmát és ha minden rendben ment, a 
szakaszkulcs segítségével már indulhat a titkosított kom- 
munikáció. Ráadásul a hitelesítő visszaküldésével az ügyfél 
és a kiszolgáló azonosították egymást. 
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5 Kerberos azonosítás (Sag a KDC által a kapcsolathoz 
generált szakaszkulcs, Kg a kiszolgáló hosszú távú kulcsa) 


A megoldás másik előnye, hogy az egyes kiszolgálóra szóló 
jegyek újra felhasználhatók, tehát az ügyfélnek nem kell 
minden kapcsolat előtt a KDC-hez fordulnia. A biztonság ér- 
dekében azonban minden jegy csak egy adott ideig érvé- 
nyes (ez az idő alapértelmezésben általában 8 óra), melyet 
a jegy adatmezőjében tárolunk. Az érvényességi idő lejárta 
után az ügyfél kénytelen lesz megújítani a jegyet. Ha az 
ügyfél kilép a rendszerből, a számítógépén tárolt jegyek el- 
vesznek, tehát belépéskor mindenképpen szükség lesz új 
szakaszjegyek kérésére. 


Jegy a jegyekhez (Ticket-Granting Ticket - TGT) 

A felhasználók hosszú távú kulcsát a jelszóból állítják elő, 
mégpedig egy egyirányú titkosító, úgynevezett , hash" al- 
goritmus segítségével. A szabvány szerint minden Kerberos 
implementációnak ismernie kell a DES-CBC-MD5 kódolást 
(ez egy kriptográfiai módszer a hash előállítására) . 

A KDC adatbázisában megtalálható az összes tartományi 
felhasználó és számítógép hosszú távú kulcsa. Amikor Alice 
a munkaállomásán bejelentkezik, az általa beírt jelszóból 
előáll egy kulcs, amit a bejelentkezéshez használni fog. A 
KDC ugyanezt a kulcsot a saját adatbázisából veszi, így lesz 
képes azonosítani a felhasználót. 

A hosszú távú kulcsot egy munkamenetben mindössze egy- 
szer állítják elő, mégpedig akkor, amikor a felhasználó elő- 
ször bejelentkezik a rendszerbe. A bejelentkezés után a fel- 
használó kap egy speciális szakaszjegyet, amit azután min- 
dennemű kapcsolat felépítéséhez és kezdeményezéséhez 
használhat (és használnia is kell) . 

Mint mondtuk, a KDC az, aki az ügyfél és a kiszolgálók kö- 
zötti azonosítást lehetővé teszi. Az ügyfél tehát, mielőtt a 
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kiszolgálóhoz menne, a KDC segítségére szorul (szakaszje- 
gyet kell kérnie tőle a kiszolgálóhoz), ezért a legelső sza- 
kaszjegy, amire az ügyfélnek szüksége van, magához a KDC- 
hez szól, hogy ezentúl ne kelljen a hosszú távú kulcsot 
használva azonosítania magát. 

Ez a speciális szakaszjegy a Ticket-Granting Ticket (TGT), 
azaz a jegy a jegyekhez. Az ügyfél a bejelentkezés után e 
jegy bemutatásával kérhet további szakaszjegyeket a KDC- 
től. A TGT egyébként teljesen hasonló az általános szakasz- 
jegyekhez, hiszen tulajdonképpen ez is csak egy jegy egy 
szolgáltatáshoz (mégpedig a KDC jegyárusához) . 

Amikor tehát a felhasználó azonosítása megtörtént, a KDC a 
további jegyek kiadásához generál Alice számára egy sza- 
kaszkulcsot (ez a bejelentkezési szakaszkulcs, logon session 
key). Ezt a szakaszkulcsot a felhasználóra vonatkozó adatok- 
kal együtt becsomagolja és a saját hosszú távú kulcsával tit- 
kosítja. Ez a titkosított adatcsomag maga a TGT. Látható, 
hogy a felhasználó a TGT-t se elolvasni, se módosítani nem 
tudja, hiszen azt a KDC titkosította, önmagának. A KDC 
ezután a szakaszkulcsot betitkosítja a felhasználó hosszú tá- 
vú kulcsával is (hiszen a kulcshoz azért neki is hozzá kell fér- 
nie), és némi, a TGT-re vonatkozó információ mellett az 
egész csomagot visszaküldi a felhasználónak. 

Az ügyfél tehát válaszul kap egy csomagot, ami két részből 
áll: az első rész a felhasználó saját hosszú távú kulcsával tit- 
kosított információ és a szakaszkulcs egy példánya, amit a 
KDC-vel való további kapcsolatok titkosítására majd felhasz- 
nálhat. A második rész a KDC kulcsával titkosított TGT, amivel 
pedig azonosíthatja magát. Az ügyfél a dekódolt szakaszkul- 
csot, az adatokat, és magát a TGT-t biztos helyre menti. 

A felhasználó jelszavát és hosszú távú kulcsát ekkor el is fe- 
lejthetjük, hiszen a KDC felé a TGT, más kiszolgálók felé pe- 
dig a majdan KDC-től kapott szakaszjegyek segítségével jö- 
het létre a kapcsolat. 


Hitelesítés tartományok között 

A KDC feladata kettős: egyrészt, a hitelesítő szolgáltatás 
(Authentication Service) TGT-ket, másrészt a jegykiszolgáló 
(Ticket-Granting Service) a már TGT-vel jelentkező ügyfelek ré- 
szére szakaszjegyeket gyárt. Ez a kettősség teszi lehetővé, hogy 
a Kerberos azonosítás tartományi határokat átlépve is működ- 
hessen. Lehetséges, hogy az ügyfél az egyik tartomány KDC-jé- 
től kapott TGT segítségével egy másik tartomány KDC-jétől kér- 
jen szakaszjegyet egy szolgáltatáshoz. A KDC szakaszjegyeket 
mindig csak a saját tartományába tartozó szolgáltatásokhoz 
adhat, hiszen csak a saját tartományában található felhaszná- 
lók és számítógépek hosszú távú kulcsával rendelkezik. 

A dolog megértéséhez kezdjük a legegyszerűbb esettel: le- 
gyen két tartományunk, Pest és Buda. Ha azt szeretnénk, 
hogy a két tartomány között létrejöhessen Kerberos hitele- 
sítés, a tartományok között is meg kell osztanunk egy kö- 
zös titkot, egy speciális kulcsot. Ez a tartományok közötti 
kulcs, az inter-domain key. 

A Windows 2000 a tartományok közvetlen megbízotti viszo- 
nyának kialakításakor ezt a tartományok közötti Kerberos kul- 
csot is létrehozza. A Windows 2000 tartományok között meg- 
bízotti viszony automatikusan alakul ki, amikor egy tartomá- 
nyi fában a meglévő tartomány(ok) mellé újat hozunk létre - 
természetesen csak a ,szomszédos" tartományok között, hi- 
szen a megbízotti viszonyok átlátszósága, tranzitív jellege 
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miatt - néhány kivételtől eltekintve - a további közvetlen 
megbízotti viszonyok (értsd: mindenki mindenkivel) létreho- 
zása nem szükséges. Az egymással közvetlen megbízotti vi- 
szonyban álló (szomszédos) Windows 2000 tartományok te- 
hát rendelkeznek közös tartományok közötti kulccsal. 
Gondoljunk csak bele, mit jelent ez a plussz egy kulcs: 
mindössze annyit, hogy egy tartomány KDC-je a tartományi 
fiókokon kívül még egy valakinek a hosszú távú kulcsát is is- 
meri: ez pedig a másik tartomány KDC-je. Magyarán, Pest 
KDC-jétől ugyanúgy kérhetünk szakaszjegyet Buda KDC-jé- 
hez, mint ahogy bármilyen más szolgáltatáshoz. 
Főhősünk, Fű Benő Pesten ül számítógépe előtt, és szeret- 
né elérni Gipsz Jakab számítógépének CD-meghajtóját, aki 
a Rózsadombon (Budán) lakik. Benő Pest KDC-hez fordul a 
kérésével. Pest KDC felismeri, hogy a kérés Buda KDC-re 
tartozik, ezért Benő tőle csak egy hivatkozó jegyet (refer- 
ral ticket) kap, aminek segítségével Buda KDC-nél érdek- 
lődhet. (Ezt a jegyet a tartományok közötti kulccsal titkosítot- 
ták.) Benő a jeggyel átússza a Dunát, és jelentkezik Buda 
KDC-nél, aki az általa is ismert tartományok közötti kulccsal 
ellenőrzi a jegy helyességét, majd egy hagyományos, immár 
a rózsadombi Gipsz Jakab szolgáltatásához szóló szakaszje- 
gyet ad Benőnek. Benő ezzel a jeggyel azután bátran jelent- 
kezhet a Rózsadombon, hiszen az pontosan olyan, mintha 
azt más, tőzsgyökeres budai felhasználó kapta volna. 
Ha kettőnél több tartományunk van, bonyolódik a helyzet. 
Általában nincs értelme annak, hogy minden tartományt min- 
den tartománnyal megbízotti viszonyba hozzunk, hiszen a 
Windows 2000 tartományok közötti megbízotti viszony tran- 
zitív, átlátszó. Ha az ügyfél és az általa igényelt szolgáltatás 
olyan két különböző tartományban található, amelyek nem 
szomszédosak (azaz nem állnak egymással közvetlen megbízot- 
ti viszonyban) , akkor az ügyfél az előző esethez hasonló mó- 
don ,végigutazhatja" a fát, míg eléri a céltartományt. 

Lássunk egy példát: adott három tartomány, Debrecen, 

Pécs és Budapest. A fa csúcsán Budapest található, azaz 

Debrecen és Pécs egymással nem áll közvetlen megbízotti 

viszonyban (Debrecennek és Pécsnek tehát nincs közös tar- 

tományok közötti kulcsa). 

Fű Benő pécsi előadása alkalmával szeretné elérni az azóta 

Debrecenbe költöző, Gipsz Jakab számítógépét: 

1. Benő Pécs KDC-től jegyet kér a debreceni Gipsz Jakab 
számítógépéhez. Pécs KDC erre csak egy, a Budapest 
KDC-hez szóló, a Pécs-Budapest közös kulccsal titkosí- 
tott hivatkozási jeggyel válaszol (mással nem is tudna, 
mert Debrecennel nincs közös kulcsa). 

2. Benő a jeggyel Budapest KDC-hez fordul, aki ismét csak 
egy hivatkozási jegyet tud adni: a jegy ezúttal Debrecen 
KDC-hez szól (a Budapest-Debrecen kulccsal titkosítva) . 

3. Benő továbbutazik, és az utoljára kapott jegyet bemu- 
tatja Debrecen KDC-nek, aki mosolyogva átnyújtja Be- 
nőnek a Gipsz Jakabhoz érvényes szakaszjegyet. 

4. A szakaszjeggyel Benő a következő nyolc órában már ví- 
gan és közvetlenül elérheti Gipsz Jakab számítógépét. 
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WINDows 2000 KERBEROS 

Alprotokollok 

A Kerberos protokoll valójában három alprotokollból áll: 

1. Authentication Service Exchange (AS): hitelesítő szol- 
gáltatás, ez azonosítja a felhasználót és állítja elő 
számára a TGT-t 

2. Ticket-Granting Service Exchange (TGS): a jegykiszol- 
gáló szolgáltatás, ami az érvényes TGT-ket bemutató 
ügyfelek számára más szolgáltatásokhoz érvényes sza- 
kaszjegyeket készít 

3. Client/Server Exchange (CS): az ügyfél és a kiszolgáló 
közötti azonosítás, a TGS-től kapott szakaszjegy alapján 


AS Exchange 

Az első két protokoll a kapcsolatot kezdeményező ügyfél és 
a KDC, az utolsó pedig az ügyfél és az általa áhított szol- 
gáltatást nyújtó kiszolgáló között zajlik. A protokollok 
megértéséhez vegyük ismét Alice-t és Bob-ot. Alice beje- 
lentkezik a hálózatba és szeretne hozzáférni Bob egy szol- 
gáltatásához. Mindegyik protokoll kérésből (KRB xxx REO0) 
és válaszból (KRB xxx REP) áll. 

Az AS kérés és válasz tulajdonképpen Alice bejelentkezése. 
A kérésben Alice elküldi a KDC-nek a saját adatait, az igé- 
nyelt szolgáltatás leírását (TGT-t szeretne) , valamint a jelszó- 
ból képzett hosszú távú kulccsal (KA) titkosított hitelesítőt. 
A KDC megkapja a csomagot, a titkosítatlan adatokból kide- 
rül számára, hogy Alice próbál meg bejelentkezni. Az adat- 
bázisából megkeresi Alice hosszú távú kulcsát (KA) és meg- 
próbálja dekódolni a hitelesítőt, ezzel azonosítja Alice-t. Ha 
sikerült és a benne található adatok (például az idő) érvé- 
nyesek, a KDC generál egy bejelentkezési szakaszkulcsot 
(SAlice) , és előkészíti a választ: 

A KDC a szakaszkulcsot (SAlice) és néhány egyéb hasznos 
adatot saját (KTGS) kulcsával betitkosítja - ez a TGT. A 
szakaszkulcsot Alice hosszú távú kulcsával (KA) is betitko- 
sítja, hogy Alice is hozzáférjen a szakaszkulcshoz. Az 
egészhez hozzáragaszt még némi nyílt információt a TGT- 
vel kapcsolatban (hiszen a TGT-ben tárolt adatokhoz Alice 
nem jut hozzá), és válaszként elküldi Alice-nak. 


LIS ti 


TGT-t kérnék Kafadatok, idő) 


KRB AS REO 


KDC 





KRB. AS REP 





hl szt 


KA(Sxwce), adatok Kics( Sur, jegyadatok) 


a KDC 


0 Az AS (Authentication Service) protokoll (S A rice 
által a TGT-hez generált szakaszkulcs, K, Alice; Kras 
a KDC hosszú távú kulcsa) s 


Amikor Alice megkapja a pozitív választ, a saját hosszú tá- 
vú kulcsával (KA) dekódolja a szakaszkulcsot (SAlice), 
majd az adatokkal a komplett TGT-vel együtt elmenti. 
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TGS Exchange 

Az AS protokoll segítségével Alice jogot formált arra, hogy 
jegyet vásárolhasson a tartomány szolgáltatásaihoz. Ezután 
a szakaszjegyek megváltása következik: 





5 A TGS (Ticket-Granting Service) protokoll (S arice a KDC 
által a TGT-hez generált szakaszkulcs, Sag Alice és Bob 
kapcsolatához generált szakaszkulcs, Kg Bob; Kracs a KDC 
hosszú távú kulcsa) 


Alice a TGS kérésben meghatározza a kívánt szolgáltatást, 
amihez a jegyet kéri. Alice a bejelentkezési szakaszkulccsal 
(SAlice) előállít egy hitelesítőt, és az egészhez mellékeli az 
elmentett TGT-t. A KDC a saját titkos kulcsával (KTGS) dekó- 
dolja a TGT-t és így hozzájut Alice bejelentkezési szakaszkul- 
csához (SAlice). Ezzel a kulccsal már ki tudja nyitni a hitele- 
sítőt, és a szokásos módszerrel ellenőrzi a kérés hitelességét. 
Ha az ellenőrzés során sikerrel járt, az adatbázisában megke- 
resi a kívánt szolgáltatás (Bob) hosszú távú kulcsát (KB) és 
előállít egy egyedi szakaszkulcsot, amit majd Alice és Bob 
fog használni a későbbi párbeszédeik során (SAB). 

Az új szakaszkulcsot (SAB) titkosítja az Alice által küldött 
szakaszkulccsal (SAlice), és a titkosított kulcshoz hozzá- 
csap még némi információt a következő szakaszjegyről. A 
szakaszjegy az új szakaszkulcsból (SAB) és számos, Bob 
számára hasznos információból áll (pl. Alice jogai, csoport- 
tagsága, stb.) - mindez természetesen Bob hosszú távú kul- 
csával (KB) titkosítva, hogy csak ő tudja elolvasni. 
Amikor Alice megkapja a választ, a bejelentkezési szakasz- 
kulcsával (SAlice) kibontja a Bob felé használható új sza- 
kaszkulcsot (SAB). A szakaszkulcsot, a szakaszjegyet, és a 
rá vonatkozó adatokat ugyancsak elmenti. 


CS Exchange 

Alice ezután már felveheti a közvetlen kapcsolatot Bob-bal. 
Alice először is, a Bob-féle szakaszkulccsal (SAB) előállít 
egy hitelesítőt, majd azt a Bob-hoz érvényes szakaszjeggyel 
együtt elküldi Bob-nak. 

Bob megkapja a csomagot, saját hosszútávú kulcsával (KB) 
kinyitja a szakaszjegyet, és megszerzi belőle a szakaszkul- 
csot (SAB), valamint hasznos információkhoz jut Alice-ről. 
A szakaszkulcs segítségével Bob már képes kibontani és el- 
lenőrizni a hitelesítőt is. 
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5 A CS (Client-Server) protokoll (S4g Alice és Bob kapcso- 
latához generált szakaszkulcs, Kg Bob hosszú távú kulcsa) 


Ha a kölcsönös hitelesítést elvárjuk, akkor utolsó lépésben 
Bob-nak is bizonyítania kell Alice felé, hogy ő valóban Bob. 
Ezt a klasszikus módon teszi: fogja az Alice által kapott hi- 
telesítőt, megváltoztatja a tartalmát (például kiveszi az 
adatokat és csak az időt hagyja benne), majd a szakasz- 
jeggyel (SAB) titkosítva visszaküldi. 

Amikor Alice megkapja ezt az üzenetet, biztos lehet benne, 
hogy azt Bob küldte, hiszen ki tudta nyitni - és vissza tud- 
ta csomagolni - a szakaszkulccsal titkosított hitelesítőt. A 
szakaszkulcshoz viszont csakis a szakaszjegyből juthatott 
hozzá, ami viszont Bob saját hosszú távú kulcsával volt tit- 
kosítva. Konklúzió: aki a hitelesítőt így vissza tudta külde- 
ni, az ismeri Bob hosszú távú kulcsát, következésképpen 
vagy Bobbal, vagy a KDC-vel állunk szemben (de a KDC nem 
tenne ilyen gonoszságot ;-) ). 
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Transact SOL 


(V. rész) 


Bevezetés 

Sok haladó SOL szerver programozó számára is ismeretlen a 
kurzorok fogalma. Pedig helyes használatuk alapvetően meg- 
határozza alkalmazásaink teljesítőképességét, különösen 
sokfelhasználós környezetben. Mit is tudnak ők? Mire valók? 
A cikk választ ad ezekre a kérdésekre. Sőt továbbmegyek. A 
cikk második felében kilépünk a tiszta SOL világból a való vi- 
lágba, és átmegyünk ADO, VB programozóba. Megtanuljuk, 
hogyan kell százmillió rekordból ezred másodpercek alatt le- 
válogatni az első pár száz sort. Semmi TOP 100, semmi va- 
rázslás, csak kurzorok. Meglepő lesz, tartsanak velem. 


Mi az a kurzor? 

Természetesen mindenki tudja a választ. Az a kis bigyó, ami 
a szövegszerkesztőben a sor végén villog, és kijelöli, hogy 
a következő karakter hová fog kerülni, ha leütjük a billen- 
tyűzet valamely gombját. És ez nem is áll messze az SOL 
Server kurzorától! 

Az SOL Server halmazokban gondolkodik. Amikor végrehaj- 
tunk egy lekérdezést, akkor annak van egy kimenete, ami 
egy n darab sorból álló halmaz, amit eredményhalmaznak 
(result set) hívunk. Amikor a WHERE feltétellel szűrjük az 
adatokat, akkor halmazműveleteket végzünk. Pl. WHERE 
Fizetés 5 100, akkor arra kérjük a kiszolgálót, hogy a teljes 
halmazból (ami például egy teljes tábla tartalma) csak azo- 
kat az elemeket tartsa meg, amelyekre teljesül a megadott 
feltétel. Nem mondjuk azt SOL-ben, hogy: 


for menjünk végig az összes soron a táblában 
ha a Fizetés 5 100, akkor rakjuk bele a 
4 kimenetbe 


next 


Azért nem kell leírnunk ilyeneket, mert az SOL nyelv halma- 
zokban gondolkodik, így elég a fenti WHERE kifejezés is. Ez 
nagyon jól van így, mert a lényegre tudunk koncentrálni, 
nem kell ciklusszervezéssel bajlódnunk. Azonban az élet 
nem ilyen egyszerű. Rengeteg helyen nem halmazokra, ha- 
nem egyedi rekordokra van szükségünk, amelyeken egy cik- 
ltusból végigszaladunk, és valamilyen műveletet végzünk a 
segítségükkel vagy rajtuk. Például írunk egy alkalmazást, 
ami kilistázza az ügyfelek tábla tartalmát. Megjelenítjük az 
ügyfelek nevét egy listában, és ha a program kezelője kivá- 
laszt egy nevet, a lista alatt megjelenik az ügyfél összes 
adata. Ha akarja, módosíthatja ezeket, majd a listában rá- 
kattint a következő ügyfélre, és azzal foglalkozik. Azért ez 
szekvenciális feldolgozás nem? Ez teljesen eltér az SOL Ser- 
ver halmazos lelkivilágától. Szaknyelven ezt a felfogáskü- 
lönbséget impedancia különbözőségnek hívjuk (több ilyet 
nem mondok, ígérem :). 

Az SOL Server teljességgel használhatatlan lenne, ha nem 
oldaná fel a két világ közötti ellentétet, az egyedi rekor- 
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dokkal foglalkozó való világ és a tiszta SOL-es halmazokból 
építkező világ között. Erre lesznek jók a kurzorok! Ők a ka- 
pu, az átjáró a két világ között. 

Képzeljünk el egy felhőt, amiben kis, masnis, sorszámozott cso- 
magocskák lebegnek. Ez az SOL eredményhalmaz. Most képzel- 
jük el, hogy jön egy óriás, aki egymásra rakja a dobozkákat, 
szépen sorban. Azt mondjuk neki: , Te, Küklopsz, add ide nekem 
a legfelső doboz tartalmát!" És ő odaadja nekünk a dobozban 
található dolgokat, információkat, egy rekord tartalmát. Majd, 
hadd mozogjon, azt mondjuk neki, hogy , Kükkancs, most ne- 
kem a legutolsó kellene!", és már a miénk is a legalsó dobozka 
tartalma. Sőt, ez a behemót olyan okos, hogy azt is megérti: 
Nagyfiú a legutóbbi előtt öttel levő doboz tartalma kellene!", 
és már adja is az alulról hatodik dobozka tartalmát. 

A kurzor pont olyan okos, mint Küki. Ha egy SOL eredmény- 
halmazra nyitunk egy kurzort, akkor a kiszolgáló kivasalja 
az eredményhalmazt, és készít belőle egy hurkát, amin vé- 
gig lehet gyalogolni. Lehet neki olyan parancsokat adni, 
mint , kettővel előre", vagy ,a legelsőt" satöbbi. És termé- 
szetesen az aktuális pozícióban található sor (rekord) ada- 
tait ki lehet olvasni, sőt lehet módosítani is. 

Másképpen fogalmazva a kurzor egy olyan nevesített ered- 
ményhalmaz, amiben a kiszolgáló mindig nyilvántartja az 
aktuális pozíciót, és amiben léptethetjük azt előre-hátra. 
Olyan ez, mint amikor a telefonkönyvben keresünk valakit. 
Az ujjunk mindig rajta áll azon a soron, amit éppen olva- 
sunk. A telefonkönyv az eredményhalmaz, az ujjunk pedig 
a kurzor, ami mindig egy bizonyos rekordra mutat. 

Az SOL Serverrel kétféle kurzort használhatunk, és a kettő 
közötti különbségtétel nagyon fontos! Az egyik típus az, 
amit Transact SOL-ben, általában tárolt eljárásokban, trig- 
gerekben használunk, és a DECLARE CURSOR kulcsszóval ho- 
zunk létre. Ezek akkor jók, ha az SOL programunkban sor- 
ról-sorra kell valamilyen műveletet végezni, olyat, amit a 
hagyományos SELECT, UPDATE stb. utasításokkal nem lehet 
megfogalmazni. A cikk első fele ezekkel fog foglalkozni. A 
másik fajta az, amit az adatbázismeghajtó programok (ma- 
napság zömében OLE-DB-n, ADO-n keresztül) valósítanak 
meg. Ezek előnye, hogy eltakarják a , piszkos részleteket", 
viszont csak valamilyen egyéb nyelven és eszközzel (VB, VC, 
stb.) lehet használni. Cikkünk második felében az ilyen tí- 
pusú kurzorokkal foglalkozunk. 


Egy egyszerű kurzor létrehozása 
Annyit már tudunk a kurzorokról, hogy kell hozzájuk valami- 
lyen lekérdezés, ami egy eredményhalmazt generál, és ehhez 
lehet valamilyen módon hozzáilleszteni egy kurzort, amivel 
azután szabadon mozoghatunk a leválogatott rekordok kö- 
zött. Nézzük meg részleteiben, hogyan néz ki ez a folyamat. 
1. Deklaráljuk a kurzort a DECLARE utasítás segítségével. Ez 
már ismerős lehet, hiszen a változókat is ezzel lehetett 
létrehozni. A különbség az, hogy a kurzor nevében nem 
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használhatunk (2-ot, ellentétben a változókkal, ahol 
meg kötelező odarakni. A deklaráció során kétféle visel- 
kedését lehet specifikálni, az egyik azt szabja meg, hogy 
a kurzor által bejárni kívánt recordset mennyire tükröz- 
ze az eredeti adathalmazban bekövetkező változtatáso- 
kat, a másik pedig azt, hogy milyen irányokban (előre- 
hátra, csak előre) lehet bejárni a kapott eredményhal- 
mazt. Itt kell megadni azt a SELECT utasítást is, aminek 
az eredményhalmaza táplálja a kurzort. Mivel a kurzorral 
bejárt rekordok már egy rendezett halmazt alkotnak, 
azért sokszor van értelme használni az ORDER BY-t is a 
rekordok rendezésére. Az eddigieknek megfelelő leegy- 
szerűsített példakód így néz ki: 


DECLARE curTest CURSOR 

FOR 

SELECT 
EmployeeID, LastName, FirstName 

FROM 


Employees 


2. Megnyitjuk a kurzort. A legegyszerűbb ezt úgy felfogni, 
mint hogy végrehajtjuk a deklarációban kijelölt lekérdezést. 


OPEN curTest 


3. Mozgatjuk, pozícionáljuk a kurzort a megfelelő bejegy- 
zésre, és felhasználjuk az aktuális pozíción található so- 
rok tartalmát. A mozgatásokat a FETCH utasítás segítsé- 
gével tehetjük meg. A FETCH FIRST ráállítja a kurzort az 
első rekordra. Ennek megfelelően a FETCH LAST az utol- 
sóra. A következő rekordot a FETCH NEXT-tel érhetjük el. 
Mivel általában rekordról-rekordra lépkedünk, ezt az uta- 
sítást használjuk leggyakrabban. Aki szeret visszafele 
bejárni egy eredményhalmazt, annak jól jön a FETCH 
PRIOR utasítás, ami az előző sorra lép vissza. 
Valamivel izgalmasabb a FETCH ABSOULTE n és a FETCH 
RELATIVE n. A nevükből elég jól kiviláglik a feladatuk. A 
FETCH ABSOULTE n a kisimított eredményhalmaz n. re- 
kordjára pozícionálja rá a kurzort, függetlenül attól, 
hogy hol állt éppen. A FETCH RELATIVE n pedig az aktuá- 
lis pozíciótól tudja n távolságra elmozgatni a kurzort. 
Ezt a két utasítást nem minden típusú kurzorra lehet 
kiadni, de ezekről majd egy kicsit később. 


FETCH NEXT FROM curTest 


4. Amellett, hogy barangolunk a kurzorral és kiolvassuk az 
általa kijelölt sor tartalmát, még módosíthatjuk és töröl- 
hetjük is az adott sort. Ezeket a lehetőségeket ritkán 
használjuk ki, de azért jól jöhetnek még. Az érdekessé- 
gük ezeknek a speciális UPDATE és DELETE utasítások- 
nak, hogy a WHERE feltételben nem egy , hagyományos" 
sort kiválasztó feltételt adunk meg, hanem a CURRENT 
OF kurzornév kifejezést, amiben a kurzornév az általunk 
definiált kurzort reprezentálja. Azaz a módosító és törlő 
utasítások valahogy így néznek ki: 

UPDATE tábla SET ... WHERE CURRENT OF kurzornév 


DELETE tábla WHERE CURRENT OF kurzornév 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
2001. 02. 


5. A Mór megtette a kötelességét, lezárjuk a kurzort. A ké- 
sőbbiekben újra megnyithatjuk anélkül, hogy újra dekla- 
rálnánk, de már nem olvashatunk ki rajra keresztül rekor- 
dokat, illetve nem pozícionálhatjuk a kurzort. 


CLOSE curTest 


6. Felszabadítjuk a kurzort. Miután megnézzük a kurzorok 
típusait, látni fogjuk, hogy a kurzorunk által bejárni kí- 
vánt eredményhalmaz fenntartása igen sok kiszolgálóol- 
dali erőforrást köthet le. Emiatt érdemes azonnal felsza- 
badítani, amint felhasználtuk az eredményeket. 


DEALLOCATE curTest 


A bejárás zegzugos részletei 

Láttuk, hogy a FETCH utasítás variánsaival keresztül-kasul 
bejárhatjuk az eredményhalmazt. De honnak tudjuk, hogy a 
végére értünk? És hogy már az elején járunk? És azt honnan 
vesszük észre, hogy az éppen kiolvasni kívánt sort valaki más 
már törölte alólunk? Nos, ezekre a státuszinformációk kiolva- 
sására hozták létre a (DOFETCH STATUS nevű függvényt 
(globális változót, ki hogy szereti). Ha a 2OFETCH STATUS 
értéke 0, akkor a megelőző FETCH utasítás sikeresen hajtó- 
dott végre, és felhasználhatjuk a kurzor által kijelölt rekor- 
dot. Ha -1-et kapunk vissza, akkor túlszaladtunk az ered- 
ményhalmazon, azaz vagy a legelső sor elé akartunk menni 
egy FETCH PRIOR-ral, vagy a legutolsón túlra a FETCH NEXT- 
tel. Ha ciklusban járjuk végig a sorokat, akkor erre szoktuk 
építeni a ciklus végét jelző feltételt. A -2 a legravaszabb. Ez 
vagy azért jön elő, mert az aktuális sort törölték, vagy pedig 
azért, mert úgy módosították az adott sort, hogy az már nem 
esik bele abba az eredményhalmazba, amit a deklarációnál 
használt SELECT jelöl ki. Például a SELECT-tel kiválasztjuk a 
budapesti alkalmazottakat, és az így leválogatott halmazban 
barangolunk a kurzorunkkal. Eközben Mariska a HR-ről átírja 
Nagy Elek lakcímét Szegedre. És mi a következő lépésben 
(FETCH NEXT) ki akarjuk olvasni Nagy Elek adatait, és kapunk 
egy nagy -2-t mert Elek már nem budapesti, így nem is lehet 
benne a kiinduló SELECT által leválogatott halmazban. Lás- 
sunk hát egy olyan példát, amiben végigmegyünk az összes 
alkalmazotton egy kurzorral: 


DECLARE curTest CURSOR 
FOR 
SELECT 
EmployeeID, LastName, FirstName 
FROM 
Employees 
OPEN curTest 
FETCH NEXT FROM curTest 


WHILE EBGFETCH STATUS 5 0 
BEGIN 

FETCH NEXT FROM curTest 
END 


CLOSE curTest 


DEALLOCATE curTest 
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Ez így nagyon szép, de mi történik a FETCH NEXT-ek során 
kiválasztott sorokkal? Ha a Ouery Analyser-ben kipróbáljuk 
az előbbi példát, akkor az alábbi kimenetet kapjuk: 


EmployeeID LastName FirstName 
ml ká bes 
(1 row(s) affected) 

EmployeeID LastName FirstName 
Til mász 


(1 row(s) affected) 


Azaz minden egyes FETCH NEXT egy új eredményhalmazt ge- 
nerál! Hát ez minden, csak nem álom (hacsak nem rémálom) 
feldolgozni egy ügyfélalkalmazásból, arról nem is beszélve, 
hogy minden egyes FETCH NEXT eredményeképpen előállt 
eredményhalmaz egyenként át kell, hogy utazzon a hálóza- 
ton. Egy sima SELECT összes sora egy nagy csomagban (itt 
nem hálózati csomagról, hanem körülfordulásról van szó) 
utazik, míg a kurzor minden egyes sora külön csomagban. Ez 
aztán az erőforráspazarlás netovábbja. Általában nem is 
használjuk így a kurzorokat, legalábbis a Transact SOL kur- 
zorokat. Hisz milyen előnyét élveztük annak, hogy a 


SELECT 
EmployeeID, FirstName 


FROM 


LastName, 
Employees 


helyett egy jó bonyolult kódot hordtunk össze? Semmit. 
Ilyen módon nem jól hasznosíthatók a kurzorok. Azonban 
a bejárás során érintett sorokat elraktározhatjuk változók- 
ba is, és ekkor lesz csak igazán nagy az örömünk. Nulla da- 
rab eredményhalmaz generálódik, a hálózaton csönd lesz, 
és mi hatékonyan, gyorsan dolgozunk kurzorunkkal a ki- 
szolgálóoldalon. Hogyan is? 

Deklarálunk lokális változókat, ezekbe rakjuk az aktuálisan 
felolvasott rekord mezőinek a tartalmát: 


DECLARE €nEmployeeID INT 
DECLARE f€cLastName VARCHAR(20) 


DECLARE €cFirstName VARCHAR(20) 


A FETCH ... utasítás után elhelyezünk egy INTO kulcsszót, 
és felsoroljuk az előbbi változóinkat, amelyekbe szeret- 
nénk belerakni a kurzor által , kiolvasott" rekord tartalmát: 


FETCH NEXT FROM 
curTest 

INTO 
(nEmployeeID, EcLastName, EcFirstName 

A felsorolt változók sorrendje meg kell, hogy egyezzen a SE- 

LECT által generált eredményhalmaz elemeinek a sorrendjével, 

hogy egymásra találjanak az értékek. 
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Hogy kerek legyen a példánk, írjunk egy olyan kódot, ami 
összegyúrja egy nagy listává az összes alkalmazott nevét, azaz 
összefűzi őket egy sztringgé. Ezt elég nehéz, ha egyáltalán le- 
hetséges megoldani ,hagyományos" SELECT felhasználásával: 


DECLARE €nEmployeeID INT 

DECLARE €GcLastName VARCHAR(20) 
DECLARE €cFirstName VARCHAR(20) 
DECLARE €cAllNames VARCHAR(4000) 


SET €cAllNames — "!"" 


DECLARE curTest CURSOR 
FOR 
SELECT 
EmployeeID, LastName, FirstName 
FROM 
Employees 
OPEN curTest 


FETCH NEXT FROM 
curTest 

INTO 
€nEmployeeID, GcLastName, cFirstName 

WHILE ÉGGFETCH STATUS - 0 

BEGIN 
SET ecAllNames - EcAllNames t 


€GcLastName 4£ " " 4 GcFirstName 4 ", 
FETCH NEXT FROM 
curTest 
INTO 
eénEmployeeID, EcLastName, écFirstName 


END 


CLOSE curTest 
DEALLOCATE curTest 
-eTeszt: 


SELECT EcAllNames AS Names 


Az utolsó teszt SELECT eredményeként láthatjuk, hogy a 
(ocAllNames tartalma: 
Fuller Andrew, 


Davolio Nancy, Leverling Janet, 


Peacock Margaret, Buchanan Steven, ... 


Kurzortípusok 

Mint korábban említettem, többféle kurzort hozhatunk lét- 
re, annak megfelelően, hogy mi a célunk a keletkező ered- 
ményhalmazzal. Nézzük végig a lehetőségeket, és azt, 
hogy mikor melyikkel érdemes élni. 

Statikus kurzorok 

Ha a kurzor deklarációja során a statikus típust kérjük, ak- 
kor az SOL Server végrehajtja a kért lekérdezést, és a tel- 
jes eredményhalmazt elhelyezi a tempdb-ben, egy ideigle- 
nes táblában. Azaz kapunk egy másolatot a lekérdezés 
eredményéből, így a megnyitás után akár le is törölhetik 
az összes sort a kiinduló táblából, mi vidáman lépkedünk a 
másolaton. Azaz ennél a kurzornál soha nem lesz a 
(OA(OFETCH STATUS értéke -2, nem lapátolják ki alólunk a 
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sorokat. Más kérdés, hogy nem is fogjuk fel, hogy közben 
elszaladt mellettünk a világ. Mivel másolaton dolgozunk, az 
aktuális sort nem is módosíthatjuk, azaz a korábban ismer- 
tetett UPDATE, DELETE nem használható erre a kurzorra. 


Deklaráció: 


DECLARE Kurzornév CURSOR STATIC 
FOR ... j 


Mikor jó egy statikus kurzor? Hmm. Igazából nem tudok jó 
felhasználást. Ha minden sorra szükségünk van, akkor kár 
az egész táblát átmásoltatni a tempdb-be, egyszerűbb le- 
kérdezni a teljes eredményhalmazt a hagyományos módon, 
mindenféle kurzor felhasználását mellőzve (ezt hívják De- 
fault Result Set-nek). Ne nagyon használjuk a statikus kur- 
zort, csak ha valami különleges indokunk van rá. 

Keyset kurzorok 

A keyset kurzor már sokkal gazdaságosabban bánik a tempdb- 
vel, mint a statikus kurzor. Nem a kurzordeklarációban előírt 
teljes sorokat tárolja le egy átmeneti táblába, csak az egyes s0- 
rok egyedi azonosítóit. Ebből következően a lekérdezésben sze- 
replő táblának kell lennie legalább egy olyan oszlopának, ami 
garantáltan azonosítja a sorokat, garantáltan egyedi. Ez lehet 
egy UNIOUE index, egy PRIMARY KEY vagy egy clustered index 
(lehet, hogy a clustered index értékei nem egyediek, de az SOL 
Server minden clustered index bejegyzéshez hozzácsatol egy bel- 
ső azonosítót, amitől azok belülről egyediek lesznek) . 

Mivel csak a kulcsokat tároljuk a tempdb-ben, a kiválasztott 
valódi sorokat lehet, hogy valaki más módosította a kurzor 
megnyitása óta. Ilyenkor a megváltozott mező értékeket 
kapjuk vissza. Ha valamelyik sort közben törölték, akkor a 
(DOFETCH STATUS -2 jelzi, hogy már nem létezik a sor, amit 
ki szeretnénk olvasni. Ha olyan értékeket szúrnak be a táblá- 
ba, aminek a deklarációban szereplő SELECT alapján benne 
kellene lennie a kurzor eredményhalmazában, nos, azokat 
nem fogjuk látni. A legenerált kulcshalmaz fix, nem változik, 
csak ha lezárjuk, és újra megnyitjuk a kurzort. Formátum: 


DECLARE curTest CURSOR KEYSET 
FOR ... 


Mikor érdemes használni ezt a kurzort? Akkor, ha csak a ki- 
választott sorokkal szeretnénk foglalkozni, és nem érdekel 
bennünket az, hogy esetleg közben további sorokat szúrtak 
be egy táblába, de érdekel bennünket a kiválasztott soro- 
kat érintő változtatási kísérlet. 

Dinamikus kurzorok 

Láttuk, hogy a statikus kurzornak mindegy mi történik a 
kiinduló adatokkal, mi vígan olvassuk a legenerált másolat 
eredményhalmazt. A keyset kurzor már figyelmesebb, a so- 
rokon végzett UPDATE és DELETE utasításokat már vissza- 
tükrözi a kurzort használó alkalmazásnak. De az INSERT-e- 
ket nem, azaz nem jelennek meg a kurzor megnyitása után 
beszúrt sorok a kurzor eredményhalmazában. Érezzük, hogy 
már csak egy lépés van hátra egy olyan kurzortípushoz, ami 
az összes változtatást átvetíti a kurzor eredményhalmazára. 
Természetesen ez a dinamikus kurzor. Ez nem nyúl a tem- 
pdb-hez (legalábbis nem jelentős mértékben). Nem hoz lét- 
re átmeneti táblákat. A kurzorral sétáló alkalmazás észreve- 
szi, ha új sort szúrnak be a táblába, mert az új sorok meg- 
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jelennek a kurzor eredményhalmazában! Nem véletlenül di- 
namikus a neve. A deklaráció nem fog meglepetést okozni: 


DECLARE curTest CURSOR DYNAMIC 


Valójában elég nehéz elképzelni, hogy az SOL Server tervezői 
hogyan valósították meg ezt a funkcionalitást. Biztos nem volt 
egyszerű. De sikerült nekik, így van egy szuperjó kurzorunk, ami 
nagyon kicsi kiszolgálóoldali terhelést okoz. Akkor jön igazán 
jól, ha egy lekérdezés kimenete nagyon nagy eredményhalmazt 
adna vissza, de nekünk ebből csak az első, például 50 sorra van 
szükségünk. Az SOL guruk ilyenkor TOP 50-ért kiáltanak, amivel 
kapásból egy 50 eleműre vágott eredményhalmazt kapunk. De 
mi van, ha nekünk csak az 550. és a 600. sor közötti rekordok 
kellenek? A TOP 600-zal leválogatom az első hatszáz eredményt 
(ami azt jelenti, hogy azok át is csurognak a hálózaton az ügy- 
félprogramra, a modemesek nagy örömére), és mi fütyülve el- 
dobjuk az első 550-et, hogy élvezzük az utolsó ötvenet. Mi nem 
akarunk ilyen pazarlók lenni, és megbecsüljük a modemezőket 
is. Ilyenkor jön jól a dinamikus kurzor. 

Mivel a dinamikus kurzor eredményhalmaza illékony, másod- 
percről-másodpercre változik, a FETCH ABSOULTE ennél a kur- 
zornál nem támogatott. Hiszen a FETCH ABSOULTE 100 ebben 
a pillanatban lehet, hogy teljesen más sort választ ki, mint 10 
másodperc múlva, ha közben 500 felhasználó püföli a tábla 
tartalmát. Ennek ellenére (surprise :), a FETCH RELATIVE mű- 
ködik. A FETCH FIRST is, így a kettőből már össze lehet rakni 
egy FETCH ABSOLUTE-ot. Hogy miért van ez így? Nem tudom. 
De működik, és ezt nagyon jól ki tudjuk használni. 

Az eddigiekből az következik, hogy a dinamikus kurzornak 
kell lenni a leggyorsabbnak, hisz ez nem épít semmilyen át- 
meneti táblát. Ez egészen addig igaz, amíg csak egy táblá- 
ból kérdezünk le. Amint illesztéssel (JOIN) több táblát 
összekapcsolunk lehet, hogy gyorsabb az elején felépíteni 
egy átmeneti táblát az összekapcsolt eredményekből, mint 
mindig menet közben összekapcsolni újra és újra a táblá- 
kat. Magyarra fordítva illesztett táblák esetén nem biztos, 
hogy a dinamikus kurzor a leggyorsabb. 

Forward only kurzor 

Az előbbi három kurzor alapértelmezésben támogatja azt, 
hogy előre-hátra mozogjunk vele az eredményhalmazban 
(SCROLL). Azonban az esetek igen jelentős részében csak 
előre akarunk végighaladni a kurzorral, mert egyszerűen 
kiíratjuk az eredményeket egy riportban vagy egy webla- 
pon. Ebben az esetben adhatunk egy kis könnyítést az SOL 
Servernek azzal, hogy jelezzük, hogy a kurzorunkkal csak 
előre fogunk lépegetni. Ezáltal a kiszolgálónak kevesebb 
munkába kerül nyilvántartani a pozíciónkat. 

A forward only nem egy negyedik kurzortípus, hanem az 
előző három kiegészítése, pontosítása. Pl. egy keyset kur- 
zor egyirányúsítása: 


DECLARE curTest CURSOR FORWARD ONLY KEYSET 
FOR ... 


Fast forward only kurzorok 

Ez a negyedik típusú kurzorunk. Ez egyetlen hálózati körülfor- 
dulásban visszaküldi a teljes eredményhalmazt a kliensre, majd 
automatikusan zárja a kurzort. Így az ügyfélprogramnak gya- 
korlatilag csak kérni kell az adatokat, és nem kell foglalkozni a 


tech.net! 


kurzor megnyitásával - bezárásával. Az ADO dokumentáció 
hallgat erről a lehetőségről, de ODBC-n keresztül el lehet érni. 
Mivel azonban manapság már nem nagyon használunk ODBC- 
t, ezzel a lehetőséggel nem nagyon foglalkozunk. Mellesleg az 
ADO , sima" forward only kurzora kísértetiesen hasonlít visel- 
kedésben erre a kurzorra. Nem véletlenül. Ha ADO-n keresztül 
csak olvasható, forward only kurzort kérünk, akkor az egy fast 
forward only (régebbi nevén firehouse) kurzor lesz. 

Jogosan kérdezheti bárki, hogy miért foglalkozunk ennyit a 
kurzorokkal, amikor olyan ritkán használjuk. Biztos? Lehet, 
hogy a Transact SOL kurzorok felhasználása elég speciális, és 
csak kevesen fognak belegabalyodni. Azonban mi történik 
akkor, amikor egy ügyfélprogram ADO vagy ODBC segítségé- 
vel végrehajt egy lekérdezést az SOL Serveren? Hmmm? Ho- 
gyan nyissuk meg a kapcsolatot a szerver felé? Ja, hogy le- 
het valamit állítani a lekérdezés végrehajtásakor? És még 
valami kurzortípust is? Ejha, nézzünk csak ennek a körmére! 


API kurzorok 

Amikor ADO segítségével végrehajtunk egy lekérdezést az 

SOL Serveren, akkor két választási lehetőségünk van. 

1. Teljes egészében letöltődik az egész eredményhalmaz a 
kliensre, és ott navigálunk a rekordok között - ekkor 
beszélünk kliensoldali kurzorról. 

2. Jelezzük, hogy kiszolgálóoldali kurzort szeretnénk használ- 
ni, és akkor csak azok a rekordok kerülnek át az ügyféloldal- 
ra, amelyekre ténylegesen rápozícionálunk, és kiolvasunk. 

A kliensoldali kurzorok akkor hatékonyak, ha kis (c1000 
sor) eredményhalmazokkal dolgozunk, és az összes sorral 
szeretnénk dolgozni. Ilyenkor a teljes eredményhalmaz - 
kiszolgálóoldali kurzor felhasználása nélkül - egy kötegben 
átmegy a kliensoldali adatbázismeghajtó programra, ami 
implementálja az eredményhalmaz navigálásához szüksé- 
ges függvényeket. A kiszolgáló gyorsan megszabadul a 
munkától, a zárolások gyorsan feloldódnak. Az ügyfélprog- 
ram akármeddig dolgozhat a rekordokon, a szervert nem 
terheli a ténykedése. És ami még fontos, a navigáció nem 
generál járulékos hálózati forgalmat. 
A kiszolgálóoldali kurzorok akkor használhatók ki jól, ha a 
lekérdezés eredményhalmaza nagyon nagy, és nem akarjuk 
feldolgozni az egészet, csak egy részét. A legtöbb böngé- 
sző, listázó típusú adat megjelenítés ilyen. Így a kliens- 
programot nem árasztja el a kiszolgáló megabájt méretű 
eredményhalmazzal, megint csak a lassú vonalak végén 
ülők örömére, és a bérelt vonali szolgáltatók bánatára. 
A kiszolgálóoldali kurzorok esetén ugyanaz a választékunk, 
mint amint a Transact SOL kurzoroknál már megnéztünk. 
Hogyan lehet elképzelni az ADO által megvalósított kurzort? 
Valahogy úgy, hogy a lekérdezés végrehajtásakor a távolban, a 
kiszolgálóoldalon létrejön egy kurzor. Nem a DECLARE CURSOR 
és az OPEN utasításokkal, hanem speciális, csak erre a célra 
használat , ál" tárolt eljárásokkal, mint az sp. cursor és társai. 
Ezek a tárolt eljárások a valóságban nem is léteznek (bár úgy 
látszanak) , hanem az SOL Server kernel tudja, hogy egy adat- 
bázismeghajtó program kiszolgálóoldali kurzort akar létrehozni, 
és ennek megfelelően belül létrehozza a kurzort. További spe- 
ciális tárolt eljárások hívásával az ügyféloldali adatbázismeg- 
hajtó program FETCH és egyéb kurzorműveletet tud végre haj- 
tatni a létrehozott kurzoron a távolban, a kiszolgálón. Ezeket 
könnyedén megfigyelhetjük az SOL Profiler felhasználásával. 
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Ezeket az adatbázismeghajtó program által létrehozott 
kurzorokat API kurzoroknak nevezzük. Nem úgy, mint a 
Transact SOL kurzorokkal, ezekkel nap mint nap találko- 
zunk, vagy tudatosan, vagy nem, hisz az ügyfélprogram, 
adatbázisműveletek használják őket. 


Írjuk meg az altavistát! 

Zárásul tegyük fel a koronát a tudásunkra. Tervezzünk egy 
olyan alkalmazást, ami képes végrehajtani egy paraméte- 
rezett lekérdezést, célszerűen olyat, aminek nagyon nagy 
az eredményhalmaza (például az altavistán rákeresünk a 
sex szóra :). Azután ebből a halmazból jelenítsük meg a 
200 és a 220. sor közötti rekordokat. 

Egy valódi, például webes alkalmazásban megjelenítenénk egy 
sorszámozott menüt, amivel a felhasználó közvetlenül kérheti 
a megfelelő lapok megjelenítését. Valami ilyesmire gondolok: 
20 40 60 80 100 120 140 160 180 200 554005 

A megoldáshoz az ADO kurzoraihoz folyamodunk. (Elnézést 
azoktól, akik szeretik a tiszta SOL kódokat, de most egy ki- 
csit át kell mennünk ügyféloldalra, és VB-re. ) 

Mivel a kedvenc Northwind adatbázisomban nincs elég nagy 
tábla, ezért létre fogunk hozni nagyon nagy teszttáblákat a 
megfelelő méretű eredményhalmaz reményében. Az Order De- 
tails tábla 2155 sorból áll. Ez elég lesz az első referenciamé- 
résünkhöz, azonban gyengus lenne demonstrációs célra, hisz 
azt ígértem a cikk elején, hogy milliós nagyságrendű táblából 
fogunk kiválogatni sorokat ezredmásodpercek alatt. Lássunk 
egy teszttáblát, amit a méréseinkhez fogunk felhasználni: 


CREATE TABLE BigTablel000000( 

nID INT NOT NULL PRIMARY KEY IDENTITY(1,1), 

nColl INT NOT NULL, 

nCol2 INT NOT NULL, 

cTextl VARCHAR(500), 

cText2 VARCHAR(500)) 
--Tartalomgeneráló kód a weben: [1] 
Nézzük meg a megjelenítést végző ügyféloldali tesztkó- 
dunkat, csak a legfontosabb részleteket tanulmányozva. 
Deklaráljuk a lapozást definiáló paramétereket! 


Dim nRecordNumber 
Dim nPosition 

200 
nRecordNumber -— 20 


nPosition 5 "Ez a kiíratandó első rekord 


"Ennyi rekodot írunk ki 
Kapcsolódjunk rá az SOL Serverre! 


Dim conTest 
"Létrehozzunk az ADO Connection objektumot 
Set conTest 5 CreateObject("ADODB.Connection") 
"Megadjuk a megfelelő connection string-et 


conTest.ConnectionString - "Provider-z..." 


"kiszolgálóoldali kurzort használunk! 
conTest.CursorLocation - adUseServer 
"Rákapcsolódunk a kiszolgálóra 


conTest.Open 
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Létrehozzuk a nagy eredményhalmazt generáló ADO parancsot. 


Dim cmdList, rsOrders 

"Létrehozunk egy ADO Command objektumot 

Set cmdList - CreateObject("ADODB.Command") 
"Hozzákapcsoljuk a már felépített Connection-höz 
Set emdList.ActiveConnection - conTest 

"Ez az SOL parancs generálja a négymilliós 
"eredmény halmazt 

cmdList.CommandText - "SELECT ..." 


Az eredményrekordokat tároló recordset létrehozása: 


"Az itt létrehozott ADO Recordset objektum 
"fogja tárolni a kiszolgálóról érkező 
"eredményhalmazt 

Set rsorders - CreateObject("ADODB.Recordset") 
"Megjelöljük a rekordok forrását 

"(a lekérdezésünket) 


Set rsOorders.Source - cmdList 
Amire kimegy a játék: 


"Minden jó anyja: a dinamikus kurzor 


rsOorders.CursorType - adopenDynamic 


"Az eredményhalmaz (és a kurzor) megnyitása 
rsOrders.Open 


rsOrders.CacheSize - nRecordNumber 


Álljunk meg egy pillanatra! Mi az a Recordset.CacheSize? 
Ezzel állítjuk be a kurzorunk szélességét. A Transact SOL-es 
példánk kurzora 1 széles volt, azaz minden egyes, a követ- 
kező rekordra navigáló lépés újabb és újabb adatbázismű- 
velettel járt. Egy, az SOL Serveren futó programnál ez nem 
is probléma, de egy ügyfél-kiszolgáló programban az lenne 
a jó, ha egyszerre több rekord is lejönne a hálózaton, így 
ritkábban kellene hozzáférni a kiszolgálóhoz további rekor- 
dokért. Erre való a CacheSize jellemző. Ha beállítjuk 10-re, 
akkor a kurzorunk 10 kövérségű lesz, így az első elemre na- 
vigáláskor nem csak az első rekord töltődik le, hanem to- 
vábbi 9 is. Így a következő 9 elemre történő navigáció nem 
igényel újabb szerverhez fordulást. 

Mozogjunk előre a 200. rekordra! 


rsOrders.Move(nPosition) 


Sok példaprogram igen helytelenül azt sulykolja belénk, 
hogy használjuk a 


rsOrders.AbsolutePosition - nPosition "nem! 


utasítást a megfelelő rekordra való mozgásra. Azonban mi 
tudjuk, hogy a dinamikus kurzornál nincs FETCH ABSOULTE, 
így ez az utasítás is elszáll a 


ADODB.Recordset (0x800A0CB3) 
Current Recordset does not support bookmarks. 
This may be a limitation of the provider or of the 


selected cursortype. 
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hibával. A hiba második része a mi problémánk. Statikus 
vagy keyset kurzorral menne az abszolút pozícionálás, csak 
akkor meg a teljesítmény lesz nagyon siralmas, ahogy azt 
majd hamarosan látjuk. 

Ránavigáltunk a 200. rekordra, most már csak végig kell 
menni a következő 20-on: 


Dim nDisplayCount 

nDisplayCount - 0 

Do While (NOT rsOrders.EOF) And 

u (nDisplayCount c nRecordNumber) 
Print rsOrders("orderID") 
nDisplayCount - nDisplayCount $1 
If nDisplayCount C€ nRecordNumber Then 
3 rsorders.MoveNext 


Loop 


Addig gyalogolunk előre a rekordokban, amíg vagy a végére 
nem érünk, vagy ki nem írattuk a kívánt számú sort. 

És természetesen takarítunk magunk után, mert nem szeret- 
jük a memóriát suttyomban fogyasztgató alkalmazásokat: 


rsOorders.Close 
Set rsorders - Nothing 
Set cmdList - Nothing 
conTest.Close 


Set conTest - Nothing 


Nem csak a szánk jár, avagy a végső terhelésteszt 

És most jöjjenek az izgalmas teljesítménymutatók, ahol ki- 
derül, hogy megbukik-e az elmélet, vagy megerősítést nyer 
(mivel ez a cikk megjelent, vélhetőleg beigazolódott :). 

A tesztkörnyezet egy 450 MHz-es PII, 128 Mbyte RAM-mal, Win- 
dows 2000 Advanced Serverrel, az ügyfél és a szerver egy gépen 
volt. Az ügyfélalkalmazás egy ASP-ben megvalósított VBScript 
kód, amely a [1] címen élőben ki is próbálható, valamint a tel- 
jes forráskód is letölthető. Az alkalmazás a fentebb ismertetett 
példa kibővített változata, de a lényege azonos azzal. 

Az SOL Server végrehajtási időket SOL Server Profiler-rel 
mértem, összeadva a parancs végrehajtásához szükséges 
összes művelet által használt időket. Az ügyfél végrehajtá- 
si időt az ASP kód kezdete és vége közt mértem, ebben ben- 
ne van a kapcsolat kiépítése, a parancs végrehajtása, a re- 
kordokon való végig gyaloglás, és a kapcsolat lezárása is. 
Az első lekérdezést az Order Details tábla ellenében hajtot- 
tam végre. 


SELECT OrderID, Ouantity FROM (Order Details] 


Ez a tábla még elég kicsi ahhoz (2155 sor), hogy az összes 
kurzort kipróbálhassuk vele - véges türelemmel is. 

A tesztben a leválogatott adatokban elmozogtam a 200. re- 
kordig, majd onnan a következő húszat írattam ki. 

Lássuk az így mért eredményeket: 
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SOL Server Ügyfél Logikai diszk 
Kurzor végrehajtási — végrehajtási művelet [lap] 
idő [sec] idő [sec] 
Dinamikus 0,001 0,03 198 etösés 
10 olvasás 
Forward only 0,01 0,02 0 írá 
írás 
4521 olvasás 
Keyset 0,110 0,13 11 írá 
iras 
í 4374 olvasás 
Statikus 0,05 0,07 7 írá 
írás 


Mit mondanak az eredmények? A dinamikus kurzort a szer- 
ver nagyon gyorsan végrehajtja, gyakorlatilag a végrehajtá- 
si időre az SOL Server Profiler 0-t ad vissza. Ennek ellenére 
kliensoldalról szemlélve a forward only kurzor teljesített leg- 
jobban, és a logikai olvasásokban is az vezet. Nem véletle- 
nül van az, hogy kis táblák tartalmának egyszerű kilistázá- 
sára javasolják a forward only kurzort. Nagyon kicsi szerver- 
oldali terhelést okoz, és a kliens nagyon gyorsan megkapja 
az eredményhalmazt. A profiler-ben látszik, hogy valójában 
ilyenkor az OLE-DB szolgáltató nem is nyit meg kurzort a 
szerveren, csak az alapértelmezett eredményhalmazt tölti le. 
Valamit azért elmond a szervernek a lekérendő eredményhal- 
maz hosszáról, ami azonban nem látszik a profiler-ben. Vi- 
szont az látszik, hogy minél több rekorddal léptetjük előre a 
(nem is létező) kurzort, annál több lapot olvas be. 

A táblázatot szemlélve egy további furcsa eredmény üti meg 
a szemünket. A keyset kurzor lassabb, mint a statikus kurzor! 
Ez ellentétben áll azzal, amit a működése alapján várnánk tő- 
le. Egy tippem van, miért van ez. A táblánk kicsi (-2000 sor). 
Ennyit a szerver pillanatok alatt átmásol a tempdb-be, ahon- 
nan a kliensnek már nagyon gyorsan, közvetlenül kiszolgálja 
a kívánt sorokat. A keyset kurzornál a kulcsokat még gyor- 
sabban be tudja másolni a tempdb-be, mint az előbbi eset- 
ben, azonban kiolvasáskor minden egyes kulcshoz elő kell 
bányászni az adatokat az eredeti táblából. Ilyen kisméretű 
táblánál nagyobb a bányászás (bookmark lookup) költsége, 
mint átmásolni az összes eredményt egy másik táblába. Ez 
nem látszik triviális módon a lekérdezésből. 

Töltsük fel a már emlegetett teszt táblánkat 10000 sorral, 
és válogassuk le az egészet (a tesztadatokat generáló 
script - terjedelmi okokból - a [1] címen érhető el): 


SOL Server Ügyfél Logikai diszk 
Kurzor végrehajtási — végrehajtási művelet [lap] 
idő [sec] idő [sec] 
Éj új 105 olvasás 
Dinamikus 0,001 0,02 0 írás 
5 olvasás 
Forward only 0,15 0,15 0 írá 
iras 
20422 olvasás 
Keyset 0,22 0,22 Ú írás 
a 20552 olvasás 
Statikus 0,25 0,26 0ifrás 


A dinamikus kurzor fittyet hány a tábla méret változtatásra, ő 
ugyanolyan gyors maradt. A forward only kurzor jelentősen 
lassult, azonban emberi léptékkel nézve még mindig villám- 
gyors. A másik két kurzor már kezd belefulladni az adatokba. 
A lapolvasások száma a tábla sorainak számával arányban 
nőtt. Ennek van egy nagyon fontos tanulsága. Ha elkészítünk 
egy alkalmazást, amiben nem ügyelünk a kurzor típusára, és 
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az statikus vagy keyset lesz, akkor eleinte jó gyorsnak fog 
tűnni a program, mert az összes sort képes benntartani a szer- 
ver a fizikai memóriában, és ott a mai processzorok nagyon 
gyorsan tudnak keresni. Ha azonban az alkalmazás éles üze- 
me során az adatok elkezdenek záporozni a táblákba, akkor le- 
het, hogy egy hónap múlva az alkalmazás kifekszik, jönnek az 
időtúllépésről szóló üzenetek, és a haragos ügyfelek. 

A helyzet akkor lesz csak igazán drámai, ha akkorára dagadnak 
a táblák, amekkorát már soha nem tud egyben benntartani a 
szerver a memóriában, így elindul a merevlemez reszelés. Ekkor 
mutatja csak ki a foga fehérjét a rossz tervezés. Nézzük csak 
meg egy 1,000,000 soros táblával az előbbi számok változását: 


SOL Server Ügyfél Logikai diszk 
Kurzor végrehajtási — végrehajtási művelet [lap] 
idő [sec] idő [sec] 
4 s 108 olvasás 
Dinamikus 0,001 0,03 0 írás 
17 olvasás 
Forward only 0,17 0,18 sé 
0 írás 
2,845,123 olv. 
Keyset 83,11 83,26 4 
3276 írás 
sű 2,988,655 olv. 
Statikus 281,466 288,68 s 
8432 írás 


Gyakorlatilag a két utolsó kurzor kiesett a játékból, az ADO 
alapértelmezett 30 másodperces parancs idejéből már rég 
kifutottak volna a parancsaink. És most csak egy felhasz- 
náló terhelte a szervert, nem 1000! Egy élő rendszer ebben 
az esetben egyszerűen leállna. Sajnos ilyen tervezési hibák 
miatt elég gyakori, hogy alaptalanul szidnak egy rendszert, 
merthogy az már egymillió sort sem tud rendesen kezelni. 
Bezzeg a pityipalkó cég terméke... 

Akkor tessék csak megnézni azt az első sort! Végrehatási idő a 
kliens oldalon mérve is 30 milliszekundum! Pedig a tábla már 
egymillió sort tartalmaz, ami messze meghaladja az én gépem 
RAM-jának tárolókapacitását. De nem is ez a lényeg. Hiába 
nőtt a tábla mérete az első esethez képest az 500 szorosára, a 
végrehajtási idő gyakorlatilag nem változott. Ezért szeretem én 
úgy a dinamikus kurzort. Szeressék Önök is, és éljenek vele! 


Zárszó 

A [1] címen nem csak példakódok találhatók, hanem min- 
den, a cikk második felében szereplő kódot interaktívan ki- 
próbálhat a kedves Olvasó, maga választva ki a mérés 
összes paraméterét, a kurzortípusokat stb. 

A kurzorok elméletének egyik sarkalatos pontja, a zárolás 
teljesen kimaradt a mostani cikkből, a szokásos terjedelmi 
okok miatt. Azonban a jövő hónapban egy teljes cikket 
szánok a zárolások lelki világának megértésére, mert - a 
kurzorokhoz hasonlóan - a nem megfelelő alkalmazásuk 
szintén ledegradálhatja az alkalmazásunk teljesítményét - 
és vele együtt minket is. 

Jó kurzorizálást kívánok a web-en és a földön egyaránt! 


Soczó Zsolt MCSE, MCSD, MCDBA 
Netacademia Kft. 


A cikkben szereplő URL-ek: 


[1] http://technet.netacademia.net/feladatok/sgl/cursor 
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Előző számunkban bekacsintottunk az ASP alapjaiba, 
szemügyre vettük a két talán legfontosabb objektumot, a 
HTTP kérést és választ jelképező Reguest-et és Response-ot. 
Akkor kimaradt néhány dolog, ezért most folytassuk ott, 
ahol egy hónappal ezelőtt abbahagytuk, azután pedig rövid 
mese következik az ASP Session mibenlétéről. E számunk 
példaprogramjai természetesen megtalálhatók a [1] címen. 


Írjunk az IIS naplójába! 

Így van, írhatunk, ha nagyon akarunk, de körültekintőnek 
kell lennünk. A Response.AppendToLog() metódusnak 
átadott szövegrész bekerül az IIS naplófájljába (tehát nem 
az Eseménynaplóba!). A szöveg nem tartalmazhat vesszőt, 
mert a naplófájl egyes mezőit vesszők választják el, és ez 
megzavarhatná a naplók későbbi feldolgozását. A bejegyzés 
csak akkor kerül be a naplóba, ha az IIS naplózás beállítá- 
sai között bekattintottuk az , URI Ouery" mezőt. 


EZT 
General Properties. Extended Properties l 
Extended Logging Options 











(7 Date ( date ) 
4 Time (time) 
Extended Properties 

MI Clent IP Address ( c-ip ) 

D User Name ( cs-usermame ) 

0 Service Name ( s-sítename ) 

( Server Name ( s-computemame ) 
DO Server IP Address ( sip ) 

0 Server Port ( s-port ) 

[MI Method ( cs-method ) 
(CT URI Stem ( cs-uti-sti 
s EAHÉTEI 
(MI Protocol Status ( sc-status ) 









5 A sikeres egyedi naplóbejegyzés kulcsa az URI Ouery 
mező engedélyezése 


Bánjunk óvatosan ezzel a lehetőséggel. Ha az IIS naplója 
W3C vagy NCSA formátumban készül, az általunk átadott 
szöveg a naplóban a kért URL helyén (W3C formátum ese- 
tén), vagy ahhoz hozzáfűzve (NCSA) jelenik meg. Ennek 
nyilvánvalóan sok értelme nincsen, ezért én azt javaslom, 
hogy az ilyen bejegyzéseket írjuk inkább szövegfájlba, vagy 
- ha mindenképpen ennél a megoldásnál akarunk maradni 
- használjuk a Microsoft IIS naplóformátumot. 


Felhasználóazonosítás névvel és jelszóval 

A webkiszolgáló tartalmának elérését sokszor korlátozni sze- 
retnénk. Szép dolog a szabadság, de előfordulhat, hogy bizo- 
nyos adatokhoz való hozzáférés előtt szükség van a felhasz- 
nálók azonosítására. A HTTP természetesen magában hordoz- 
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za ennek lehetőségét is, és az sem kétséges, hogy a felhasz- 
nálónevet és jelszót kérő kis ablakkal már mindannyian talál- 
koztunk. De vajon tudjuk-e, mi zajlik ilyenkor a háttérben? 
Először is, a böngésző egy hagyományos kérést küld a kiszol- 
gálónak. Amikor az alapértelmezett anonymous felhasználó 
(aki az IIS esetén egyébként megfelel az IUSR számítógépnév 
felhasználónak) nem jogosult egy kért erőforrás elérésére, a 
kiszolgáló egy ,401 Unauthorized" üzenettel válaszol: 


HTTP/1.1 401 Unauthorized 
Server: Microsoft-IIS/5.0 
Date: Mon, 05 Feb 2001 21:05:25 GMT 
WWW-Authenticate: Negotiate 
WWW-Authenticate: NTLM 

WWW-Authenticate: Basic realm-"localhost" 
Content-Length: 0 

Content-Type: text/html 


Cache-control: private 


A lényeg az aláhúzott sorokban van: mindenekelőtt, termé- 
szetesen a legfontosabb a 401-es kódú HTTP válaszüzenet, 
ami azt jelzi az ügyfélnek, hogy a hozzáférést megtagadtuk. 
A WWW-Authenticate HTTP fejlécek a lehetséges felhaszná- 
lóazonosítási módszereket jelzik. Ezekből természetesen 
több is van, bár az Internet Explorer kivételével szinte min- 
degyik böngésző csak a Basic azonosítást ismeri. A Basic 
azonosítással viszont két nagy baj van: 

1. A Basic felhasználóazonosítás során a jelszó kódolatlanul 
utazik a hálózaton mindaddig, amig valamilyen kiegészítő 
megoldással (pl. https://) ezt át nem hidaljuk 

2. Az IIS5 alapértelmezésben nem engedélyezi a Basic típu- 
sú azonosítást; ez természetesen azt jelenti, hogy az Inter- 
net Explorer-en kívül más böngészővel csak az anonymous 
által egyébként is elérhető oldalakhoz férhetünk hozzá. 

A használható felhasználóazonosítási módszerek listáját és 
beállításait az adott webhely tulajdonságlapján, a Directo- 
ry Security fülön, az Anonymous access and authentication 
control mezőben található Edit... gombra kattintva megje- 
lenő dialógusablakban találjuk: 
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Authentication Methods 


TV TÁNONONK EDOM E E zt sz ue e] 
J No user name/password reguired to access this resource. 

I 

I 


! Account used for anonymous access: Edit... 
L 





TEÁLÁNOTÁER NÉ EGE e kn 
! Forthe following authentication methods, user name and password are. ) 
! reguired when 
- anonymous access is disabled, or 

- access is restricted using NTFS access control lists 
[7 Basic authentication (password is sent in clear text) 

Select a default domain: 

TT Digest authentication for win 
[7 integrated Windows authentication 


OK Cancel Help 
a A Basic (nyílt jelszavas) felhasználóazonosítás nem 
alapértelmezés, itt kapcsolhatjuk be 

















Alapértelmezés, hogy felhasználóazonosításra akkor van 
egy adott feladathoz már nem elegendők. 
Felhasználóazonosítást tehát legegyszerűbben úgy kény- 
szeríthetünk ki, ha az NTFS fájlrendszerre telepített IIS 
könyvtára alatt (ez az linetpublwwwroot) a kívánt fáj- 
lo(ko)n vagy könyvtár(ak)on korlátozzuk az IUSR számító- 
gépnév felhasználó hozzáférési jogait. Az IIS ilyenkor auto- 
matikus felhasználóazonosításba kezd, és csak akkor enge- 
di ,be" a felhasználót, ha őt a megadott jelszó segítségé- 
vel a felhasználói adatbázisban sikeresen azonosította. 

Ha ezt nem akarjuk, az azonosítást kérhetjük kódból is: 
mint már tudjuk, a felhasználóazonosítást tulajdonképpen 
egy 401-es kódú HTTP válaszüzenet váltja ki. Vajon mi tör- 
ténik, ha a Response.Status segítségével mi magunk küld- 
jük vissza ezt az üzenetet, valahogy így: 


£xt Response.Status 5 "401 Unauthorized" 85 


Nos, elárulhatom, hogy a legjobbak történnek. A státuszüzenet 
mellé az IIS automatikusan mellékeli a megfelelő WWW-Authen- 
ticate mezőket és elvégzi helyettünk a felhasználóazonosítást. 

A felhasználó neve, jelszava (ha elérhető) és a felhaszná- 
lóazonosítás típusa bármikor megtalálható a ServerVariab- 
les kollekcióban: 


Reguest.ServerVariables ("AUTH TYPE") 
Reguest.ServerVariables ( "AUTH USER") 
Reguest.ServerVariables ( "AUTH PASSWORD") 


A jelszó csak akkor látható, ha a típus , basic"; más esetek- 
ben az AUTH PASSWORD mező értéke üres. Ha nem volt 
felhasználóazonosítás (pl. mert anonymous módon értük el 
az adott scriptet), az AUTH USER értéke is üres lesz. Lás- 
sunk ezután egy példát, ami felhasználóazonosítást kér, 
majd ha az sikeres volt (azaz ha az IIS a Windows 2000/NT 
felhasználói adatbázisában a felhasználót megtalálta) , kiír- 
ja a fenti adatokat (logon.asp): 
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cg 
If Reguest.ServerVariables( "AUTH USER")-"" Then 
Response.Status - "401 Unauthorized" 
Response.End 
End If 
sz 
LHTML2 


,xaHEADPCTITLE2User LogOn Pagec/TITLE2C/HEAD2 

LBODY2 
AuthType: c 5 
4 Reguest.ServerVariables("AUTH TYPE") $2CBR2 
Username: C$ — 
HW  Reguest.ServerVariables( "AUTH USER") $2CBR2 
Password: c 5 
4 Reguest.ServerVariables( "AUTH PASSWORD" )$2 
SBR2 

£/BODY5 

€/HTML2 


A fenti kód első része ellenőrzi, hogy a felhasználó azonosí- 
totta-e már magát. Ha nem (a felhasználónév üres), vissza- 
küldi a státuszüzenetet, majd befejezi az oldal végrehajtását. 
Miután a felhasználó bejelentkezett, a vezérlés már eljut a 
valódi tartalomhoz: kiírjuk a felhasználóazonosítás típusát, a 
nevét és jelszavát. Érdemes megfigyelni, hogy a különféle 
böngészők és azonosítási módszerek hogyan befolyásolják az 
adatokat: Basic azonosítás esetén például látható a jelszó, 
míg a Negotiate módon azonosított felhasználó nevében 
benne van a tartomány neve is (a 1 jel előtti rész) . 






AZ user Logon VET ea] 
] File Edit View  Favorites Tools Help 









AuthType: Negotiate 
Username: TWILIGHTbeno 


Password: 


(8) 00ne Skz ízábati 


File Edit View Go 


iza 


JA Location: http://localhost/aspsuli2/logon. asp 


AuthType: Basic 
Usemame: beno 
Password: pass 


Document: 1718 ts 39 EJ 4] 4 





0 Ugyanaz az oldal, bejelentkezés után az Internet 
Explorer és a Netscape esetében. Jól látható a tarto- 
mány neve, illetve a Netscape oldalán a nyílt jelszó 


A felhasználóazonosítás egy másik, új, IIS5-ben bemuta- 
tott módja a tanúsítványokkal, felhasználónév és jelszó 
nélkül történő, automatikus azonosítás; erről egy későbbi 
alkalommal beszélünk majd. 
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Egy megjegyzés a Reguest kollekciókról 

A Reguest objektum lehetővé teszi, hogy a különböző 
kollekciókban található adatokat a forrás megadása 
(pl. Reguest.Form(,,nev")) nélkül, közvetlenül a Reguest(, nev") 
hívással érjük el. Ilyenkor az IIS az összes kollekción végig- 
fut, és visszaadja az adott nevű elem első előfordulását. 
A sorrend a következő: 

"b OueryString 

"8 Form 

"0 Cookies 

0 ClientCertificate 

"0 ServerVariables 

Néha hasznos lehet, de általában nem jó, ha ezt a közvetlen hi- 
vatkozást használjuk: egyrészt, feleslegesen terheljük vele a ki- 
szolgálót, másrészt pedig, nem lehetünk biztosak abban, hogy 
az adat onnan jött, ahonnan mi vártuk. Képzeljük el, hogy egy 
kérdőív , név" mezőjét szeretnénk beolvasni, ehelyett azt kap- 
juk, amit a felhasználó kézzel begépelt az URL végére! 


Az ASP alkalmazás és munkamenet 
Lássuk csak újra az előző számban bemutatott ábrát az IIS 











IIS Motor 






Session objektum a 
sa 
és 


"b Reguest objektum " ff v 


tve. 


Ügyfél 
""s Response objektum 


Session objektum 


"b Reguest objektum 


ASP Error 
objektum 


""" Response objektum 





Ügyfél 


Jól látható - és remélem, mostanra nyilvánvaló is -, hogy az 
eddig tárgyalt objektumok, a Reguest és a Response mindig 
egy aktuális HTTP kérést és az arra adott választ jelképezik. A 
következő kérés esetén mindkét objektumból új keletkezik. A 
következőkben az alkalmazás (Application) és a munkamenet 
(Session) objektumokról lesz szó. Ezek az objektumok már 
nem tűnnek el ilyen egykönnyen az IIS memóriájából, hiszen 
feladatuk pontosan az, hogy több kérést is átfogó művelete- 
ket, központi adattárolást tegyenek lehetővé. 


Az ASP alkalmazás 

Mit nevezünk ASP alkalmazásnak? Egy ASP alkalmazás tulaj- 
donképpen nem más, mint egy adott könyvtárban és az 
összes alkönyvtárában található .asp kódok halmaza. Csak- 
hogy a valóságban ennél kicsit bonyolultabb a helyzet, hi- 
szen ha csak erről lenne szó, nem lett volna szükség az al- 
kalmazások létrehozására. 

Mint tudjuk, a HTTP eredetileg állapotmentes világ: jön egy 
kérés, mi kiszolgáljuk, azután jön a következő, és a kiszol- 
gálónak végülis fogalma sincs arról, hogy melyik kérést ép- 
pen ki küldte. Lehet, hogy ugyanaz a felhasználó, lehet, 
hogy a világ két végéről két olvasó jelentkezett. Mégis, mi- 
lyen jó lenne, ha lenne egy globális , valami", amiben ada- 
tokat, sőt, akár kész objektumokat tárolhatunk, és bármikor 
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szükség van rá, csak , fel" kell nyúlnunk érte, és hopp, máris 
a rendelkezésünkre áll! Nos, pontosan erre való az Applica- 
tion objektum. Segítségével a felhasználók, kérések között 
adatokat oszthatunk meg egyszerűen, anélkül, hogy például 
lemezre kellene írnunk azokat. Az Application objektumba 
írt információ mindaddig megmarad, amíg az adott alkal- 
mazást (gyakorlatilag az IIS-t) újra nem indítjuk. Amint az 
ábrán is látható, az ASP alkalmazás egy nagyszerű globális 
,felhő" a felhasználók kérései és az azokra adott válaszok 
fölött. Fontos, hogy Application objektum minden ASP al- 
kalmazásban csak egy van. 


Az ASP munkamenet 

Ha már így belemelegedtünk a felhőkbe: az ASP munkame- 
net (Session) célja teljesen hasonló, csakhogy ez az Appli- 
cation-nel ellentétben nem felhasználók közötti, hanem 
egy adott felhasználó műveletei fölötti globális objektum. 
Ha úgy tetszik, számos Reguest és Response fölött uralko- 
dó valami, ami megmarad egészen addig, amig a felhaszná- 
ló el nem hagyja a webhelyet, vagy be nem csukja a bön- 
gészőjét. Természetesen Session objektumból már nem csak 
egy van: ahány felhasználó, annyi Session. 

Hoppá! Nem tűnik fel valami? Az előbb éppen azt mondtam, 
hogy a HTTP állapotmentes protokoll. Akkor hogyan tudjuk 
megkülönböztetni Jenő és Benő különböző kéréseit Benő 
két, egymás után küldött kérésétől? (Csak semmi trükk az IP 
címekkel: természetesen Jenő és Benő ugyanazt az IP címet 
használják, de akár az is előfordulhat, hogy , menet közben" 
Benő IP címe megváltozik) . 

Nos, a válasz egyszerű: cookie. Az IIS trükkös kis sütit küld 
minden felhasználónak, akit azután felismer mindaddig, 
amig a cookie megmarad (márpedig az csak addig marad 
meg, amig a böngészőt be nem zárjuk). Nézzük csak meg, 
mit mond az IIS egy teljesen átlagos kérésre: 


GET /default.asp HTTP/1.1 


HTTP/1.1 200 OK 

Server: Microsoft-IIS/5.0 

Date: Mon, 12 Feb 2001 22:21:53 GMT 
Content-Length: 2354 

Content-Type: text/html 

Set-Cookie: 

H  ASPSESSIONIDGOGOGVDO-IBGLAICAJDOELPGDLNDPODPM; 
GW pathr/ 


Cache-control: private 


Kapunk egy érdekes nevű cookie-t: az (egyébként változó) ASP- 
SESSIONIDxxxxxxxx nevű cookie tartalmának segítségével az IIS 
egyértelműen azonosítja a visszatérő böngészőt, és ugyanabba 
a környezetbe helyezi (azaz, mindenki az első látogatáskor részé- 
re létrehozott, különbejáratú Session objektumba pottyan). 


Elbúcsúzhatunk a munkamenetektől, ha a felhasználó bön- 
gészője visszautasítja a cookie-kat. Ha ilyenkor mégis vala- 
mi hasonló funkcionalitást szeretnénk elérni, külső gyártó 
termékeit kell használnunk, amelyek az URL-be ágyazva va- 
lósítják meg a munkamenetek kezelését (az IIS-ben szűrő- 
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ként működve minden, az oldalakban található URL hivat- 
kozáshoz hozzáfűzik az azonosítót, míg a böngészöktől ér- 
kező kérésekből kiszűrik azokat). Ez a megoldás teljesen 
cookie-mentes, és elvileg minden böngésző boldogul vele 
(csak kicsit rondák lesznek az URL-ek). 


Természetesen kell, hogy legyen egy bizonyos időkorlát is: 
ha valaki 20 percen belül nem jelentkezik, a részére létre- 
hozott Session objektum elveszik, és legközelebb újra tisz- 
ta lappal indul. Ez az időkorlát is beállítható, mégpedig 
ugyanott, ahol az előző számban alapértelmezett script- 
nyelv beállításait megtaláltuk: 
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App Mappings. App Options ] App Debugging 


Application Configuration 
! [7 Enable session state 
! Session timeout. [20 minutes 
! (7 Enable buffering 
! [7 Enable parent paths 


! Default ASP language: fVeSept 
I ASP Script timeout: 190 seconds 


a A Session időtúllépése alapértelmezésben 20 perc 
Ha nincs rá szükségünk, a munkamenetek kezelését itt egy 
kattintással letilthatjuk (hiszen semmi sincs ingyen). Ha glo- 
bálisan ezt nem akarjuk megtenni, akár oldalanként is kikap- 
csolhatjuk, az oldal tetejére írt ASP direktíva segítségével: 


C$SGENABLESESSIONSTATE-"False"35 


A Session objektum 

Jó szokásunkhoz híven, haladjunk ismét hátulról előre: ismer- 
jük meg a Session objektum rejtelmeit. Mindenekelőtt, próbál- 
gassuk a sessionid.asp oldalt! Nyissunk meg egy böngészőt, 
nyissuk meg az oldalt, vándoroljunk tovább, térjünk vissza, és 
figyeljük meg, változik-e a Session azonosítója! Nyissunk meg 
egy másik böngészőt, és láthatjuk: ahány böngésző, annyi Ses- 
sion. Az oldal egyetlen említésreméltó sort tartalmaz: 


Session ID: c$ 5 Session.SessionID 385 


A Session.SessionID jellemző visszaadja a Session azono- 
sítóját. Ez az azonosító sokszor jó szolgálatot tehet, hiszen 
segítségével azonosítani lehet a visszatérő felhasználót. 
(Mielőtt valaki félreértené: visszatérő alatt most azt értjük, 
aki a Session időkorlát lejárta előtt ,, visszatér", vagy azalatt 
barangol oldalainkon) . 

A Session.LCID és a Session.CodePage jellemzők a szoká- 
sos locale és karaktertábla-azonosítók; az objektum negye- 
dik, s egyben utolsó jellemzője pedig a Session.TimeOut, 
amit átállítva egy adott munkamenet erejéig felülbírálhat- 
juk az alapértelmezett 20 perces időkorlátot. 

Sokkal érdekesebb ennél az, amire a Session objektumot 
eredetileg kitalálták: írhatunk bele és olvashatunk belőle, 
gyakorlatilag bármit; a beleírt érték pedig természetesen 
megmarad mindaddig, amíg az objektum életben van. A 
session.asp bemutatja mindazt, amit a Session objektumról 
tudni kell. Lássuk, hogyan tárolhatunk el egy értéket, hogy 
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azután később felhasználhassuk: 


Session("counter") -— 1 
Session("counter") - Session("counter") t1 
x - Session("counter") 


A session.asp első részében a Session(, counter") értékének 
megfelelően köszöntjük a látogatót. Érdekes még az oldal 
alján található adat is: a Session.Contents ugyanis egy 
kollekció, aminek segítségével visszanyerhetjük mindazt, 
amit sikerült az objektumba belapátolnunk (anélkül, hogy 
tudnánk a nevét), valahogy így: 


For Each oltem In Session.Contents 
Response.Write(Session(" § oltem a ") — " 8 
3 Session(oltem) £ "cbr2" ) 


Next 


Ebből a kollekcióból persze törölni is lehet. Az alábbi példa 
első két sora egy-egy elemet (pl. a , counter" nevűt, vagy ép- 
pen a másodikat) , míg a harmadik a teljes tartalmat törli: 


Session.Contents.Remove( "counter" ) 
Session.Contents.Remove(2) 


Session.Contents.RemoveAll() 


A tartalom tehát ilyenkor elveszik, de az objektum megma- 
rad. Azért fontos ezt megemlíteni, mert a Session objektu- 
mot önmagát is lehet törölni: 


Session.Abandon() 


A Session. Abandon() hívás után (természetesen miután az 
adott oldalt már végleg kiküldtük) a Session objektum tör- 
lődik a memóriából. A felhasználó legközelebbi jelentkezé- 
sekor új, üres objektum jön majd létre. Érdemes megfigyel- 
ni a session.asp és az abandon.asp kódok viselkedését. 
Természetesen nem csak számot és szöveget tárolhatunk a 
Session-ben, hanem akár komplett objektumokat is. Emlék- 
szünk még az előző számban használt ADODB.Stream ob- 
jektumra, amivel binárisan tudtunk olvasni a lemezről és 
adatot küldeni a böngésző felé? Valahogy így: 


Set oStream - Server.CreateObject("ADODB.Stream") 
oStream.Type - 1 ! adTypeBinary 
oStream.Open 


oStream.LoadFromFile( Server.MapPath("ms.jpg") ) 


Response.ContentType - "image/jpeg" 


Response.BinaryWrite( oStream.Read ) 


Vágjuk ketté ezt a kódot, és az oStream objektumot hasz- 
náljuk átmeneti tárolóhelynek! A loadpic.asp betölti az ob- 
jektumot a Session-be: 


cz 
Set ostream - 
4 Server.CreateObject( "ADODB.Stream" ) 
osStream.Type - 1 " adTypeBinary 


ostream.Open 
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oStream.LoadFromFile( Server.MapPath("ms.jpg") ) 


Set Session("mypic") - oStream 


32 


A showpic.asp pedig kiolvassa és elküldi a böngészőnek: 


zt 
If IsObject( Session("mypic") ) Then 
Set oStream - Session( "mypic") 
Response.ContentType - "image/jpeg" 
Response.BinaryWrite( oStream.Read ) 
Else 
35 
LxHTML2CHEAD2C/HEAD2 
SLxBODY?A kép nem található.€/BODY2 
£/HTML2 
cz 
End If 
sz 


A kód elején található ellenőrzés azért kell, mert ha a 
Session(, mypic") nem tartalmazza még az objektumot (például 
mert a loadpic.asp-t még nem futtattuk, vagy Abandon() hívásá- 
ra került sor), akkor az értékadás azonnal hibát jelezne. Az 
IsObject() függvény értéke akkor igaz, ha a neki paraméterként 
átadott változó tényleg egy objektum - ha nem az, a kép he- 
lyett egy egyszerű HTML hibaüzenetet küldünk vissza. 

Figyeljük meg, hogy az objektumok kezelésénél - a más típu- 
sú változókkal ellentétben - használnunk kell a Set utasítást: 


Set oStream - Server.CreateObject("ADODB.Stream" ) 
Set Session("mypic") 5 oStream 


Set oMyObj 5 Session("mypic") 


A global.asa fájl 
Most egy kicsit előreugrunk az időben: a global.asa fájl tu- 
lajdonképpen az Application objektum leírásánál kellene, 
hogy előkerüljön, azonban az a következő hónapra csúszik. 
A fájl azonban tartalmazhat a Session objektumra vonatko- 
zó részeket is, ezért a tárgyalásától nem tekinthetünk el. 
A global.asa fájl egy speciális állomány, amit az ASP alkal- 
mazás gyökérkönyvtárában lehet elhelyezni (az alapértel- 
mezett ASP alkalmazás gyökérkönyvtára például természete- 
sen az linetpub Iwwwroot). A fájl arra való, hogy ebben he- 
lyezhessük el a globális objektumokat létrehozó és -esemé- 
nyeket kezelő kódrészleteket, úgyismint: 

"b Az Application objektum eseményeit (létrehozását, 
megsemmisítését) kezelő rutinok (Application OnStart 
és Application OnEnd) 

"b A Session objektumok létrehozását és megsemmisítését 
kezelő eljárások (Session OnStart és Session OnEnd) 

- Globális objektumok létrehozása az cOBJECT: elem 
segítségével 

"0 Típuskönyvtárak (type libraries) betöltése 

A Session OnStart szubrutin értelemszerűen az adott Sessi- 

on létrejöttekor, a Session OnEnd pedig az objektum meg- 

semmisülése előtt fut le. Ezeket a rutinokat a global.asa fájl- 
ba cSCRIPT5c/SCRIPT: elemek közé kell megírnunk, például: 
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(XSCRIPT LANGUAGE-VBScript RUNAT-Server? 

Sub Session OnStart 
Session("starttime") - Now 
Set Session("oFSO") - Server.CreateObject 
4 ("Seripting.FileSystemobject") 

End Sub 


Sub Session OnEnd 

Set Session("oFSO") - Nothing 
End Sub 
£/SCRIPT2 


A fenti példában a Session létrejöttekor beleírjuk a pontos 
időt, és létrehozunk egy FileSystemObject objektumot, amit 
a továbbiak során majd kényelmesen használhatunk, a 
Session OnEnd szubrutinban pedig felszabadítjuk az 
FilegystemObject objektum által lefoglalt memóriaterületet. 
Objektumokat globálisan is létrehozhatunk, az cOBJECT- 
elem segítségével, például: 


LOBJECT RUNAT-Server SCOPE-Session ID-"oGlobFSO" 
B PROGID-"Scripting.FileSystemobject"5 


LxaSCRIPT LANGUAGE-VBScript RUNAT-Server? 
£/SCRIPT2 


Az így létrehozott objektumokra azután alkalmazásszerte az 
.asp oldalakban közvetlen nevükkel hivatkozhatunk: 


cz 
If OGlobFSO.FileExists(strFileName) Then 
End If 
a 
Az cOBJECT: elem SCOPE paramétere határozza meg, hogy az 
objektum hány példányban n létre. A paraméter értéke ese- 


tünkben természetesen , session", ami azt jelenti, hogy minden 
egyes Session létrejöttekor újabb FileSystemObject keletkezik. 





A StaticObjects kollekció 

Egyetlen kollekció maradt a végére: a Session.StaticObjects 
kollekció a global.asa-ban , session" scope-pal létrehozott 
objektumokat tartalmazza. A kollekció tartalmát a szokásos 
módon érhetjük el (ld. session.asp): 


For Each oltem In Session.StaticObjects 
Response.Write( "Session(" § oltem § ") — " § 
4 Session(oltem) §£ "cbr5" ) 


Next 
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Bevezető 

Egyre inkább elfogadott az a nézet, hogy a sikeres működés- 
hez a csoportmunka nélkülözhetetlen, mert a csoportmunka- 
alkalmazásokat használó cégek hatékonyabb működésre ké- 
pesek. Mi is bizonyíthatná ezt jobban, mint az üzleti intelli- 
gencia és projektinformációk elérhetőségét fokozó eszközök 
iránti megnövekedett kereslet? Nem elég azonban a szellemi 
munkások rendelkezésére álló információ mennyiségét növel- 
ni, szükség van az ismeretkezelést biztosító eszközökre is. 
A Microsoft Project Central, és az azt megjelenítő digital 
dashboardok fejlett csoportmunka lehetőségeket kínálnak, 
és az Interneten és intraneteken fellelhető információk 
elérhetőségét és rendelkezésre állását kihasználva biztosít- 
ják az üzleti intelligenciához való hozzáférést. A digital 
dashboardok jobb ismeretkezelést biztosítanak, mert egy 
helyre gyűjtik a személyes, a csoportos, a céges és a külső 
információkat, és belőlük egyetlen kattintással elérhetők az 
elemző- és csoportmunka eszközök. 

Mivel széles körben elérhető webes technológiákon, vala- 
mint a Microsoft Internet Explorer 5.0 és a Microsoft Out- 
look már ismert kezelőfelületén alapulnak, a digital dashbo- 
ardok egyszerű használatot és fejleszthetőséget biztosíta- 
nak. Ezenkívül gyakorlatilag végtelen mennyiségű informá- 
cióval, és az ezek elemzéséhez szükséges eszközökkel látják 
el a felhasználókat, így a digital dashboard az egyik legha- 
tékonyabb és legrugalmasabb ismeretkezelő megoldás. 
Cikkünkben egy, a Project Central funkcionalitását biztosí- 
tó digital dashboard megoldást ismertetünk. Áttekintjük a 
megoldás által biztosított a előnyöket, és egy kis csemegét 
adunk a fejlesztőknek, akik hasonló megoldások megvalósí- 
tásán törik a fejüket. 


Egy kis áttekintés 

A Project Central a Microsoft Project 2000 webes , társa". Azért 
készült, hogy több felhasználó legyen bevonható a projektek 
tervezésébe és követésébe, valamint az ütemtervek és jelenté- 
sek elkészítésébe. A Project Central biztosítja a projektek álla- 
potának megtekintéséhez szükséges eszközöket, de használatá- 
hoz nem kell különösebb jártasság a projektvezetésben. 

A Project Central elérhetővé teszi az információkat, a digital 
dashboard pedig eljuttatja azokat a szellemi munkásokhoz, 
lehetővé teszi számukra elemzésüket, és a velük való munkát. 
A digital dashboardok testreszabott Office 2000 megoldások, 
melyek a személyes, csoportos, céges és külső adatok össze- 
vonásával az érdekes információkat közvetlenül a dolgozók 
asztalára helyezik, és ehhez egy barátságos környezetet biz- 
tosítanak, mely elérhető az irodában, de akkor is, ha a fel- 
használó éppen úton van. A digital dashboard egyszerűsíti az 
információk megtalálását is, mert az érdektelen információkat 
kiszűri, ezzel is fokozza a hatékonyságot és termelékenységet. 
Ahogy a digital dashboard egyre népszerűbbé válik, ez lesz 
az információink megosztására napi tevékenységeink és 
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projektjeink állapotának követésére szolgáló elsődleges 
eszköz. A digital dashboard rendszereknek jelentős hatása 
lehet a hatékonyságra, mivel egész egyszerűen arra terelik 
a dolgozók figyelmét, amit cégük mutatni akar nekik. A 
pontos ütemezési és tervezési információk megjelenítésé- 
nek és elérhetőségének javításával a Project Central digital 
dashboard felgyorsíthatja a vállalaton belül a projektszem- 
lélet elterjedését és megérését. 


Határtalan funkcionalitás 

A digital dashboard legfőbb erénye az, hogy gyakorlatilag 
bármilyen információt tartalmazhat. Képes egymás mellett 
megjeleníteni például az ütemezési- és projektadatokat, a 
cég alkalmazásaiból érkezett üzeneteket, Internet és intra- 
net lapokat, csoportos mappákat és személyes fájlokat. A 
digital dashboard átszabható a cég vagy munkacsoport 
egyedi igényeinek megfelelően, és integrálhatja a Project 
Central csoportmunkatervező és -követő eszközeit más ter- 
mékek elemző- és csoportmunkaeszközeivel, például az Of- 
fice 2000, a Microsoft Exchange Server, a Microsoft SOL Ser- 
ver eszközeivel, vagy más meglevő vállalati rendszerekkel. 


A Project Central funkcionalitása 

A Project Central-lal a felhasználók testreszabottan tekinthe- 
tik meg a projektek információit, saját igényeiknek megfelelő 
vagy a projektvezető, esetleg a rendszergazda által engedélye- 
zett részletességgel. A csoporttagok a projekttel kapcsolatos 
feladataik listáját, az erőforrásfelügyelők és üzletfejlesztési ve- 
zetők pedig a projektinformációk tömör vázlatát láthatják. 
Egy digital dashboard megoldás a Project Central-ban elérhe- 
tő bármely funkciót tartalmazhatja. A digital dashboard felü- 
leten belül az egyéni Gantt diagram a megszokott oszlopdiag- 
ram formátumban jeleníti meg a beütemezett feladatokat, a 
Timesheet (időtábla) nézetben pedig a felhasználók frissíthe- 
tik folyó ügyeiket, vagy feladatokat adhatnak át és hozhatnak 
létre (a projektvezető által adott jogosultságoktól függően). 





5 Egy Project Central-t megjelenítő digital dashboard. 
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Egyéb csoportmunka-támogatási lehetőségek 

Mivel a digital dashboardok Internet Exploreren vagy Out- 
look 2000-en belül futnak, beléjük építhető rengeteg más 
csoportmunka alkalmazás, és mert Office 2000 alapúak, 
hozzáférést biztosítanak a valósidejű eszközökhöz is, pél- 
dául a Microsoft NetMeeting konferenciaszoftverhez és a 
Microsoft Windows Media lejátszóhoz, melyek segítségével 
együttműködhetnek munkatársaikkal, szakértőket hívhat- 
nak segítségül, vagy akár oktatásban részesülhetnek. 
Emellett a digital dashboard fejlesztők gyakorlatilag bármit 
alkalmazhatnak, például webes vezérlőket, HTML elemeket, 
külső adatforrások elérését. 


Egy Project Central alapú digital dashboard építése 
Legegyszerűbb formájában egy digital dashboard egy dina- 
mikus weblap, mely egy Internet Explorer 5.0 böngészőn 
vagy az Outlook-on belül fut, ezért biztosíthatja a weblapo- 
kon és webes alkalmazásokban elérhető összes funkcionali- 
tást, és ezért érheti el az Office 2000 szolgáltatásait. A di- 
gital dashboard adatelérést, gazdag információkat, interak- 
tivitást, az adatokhoz való hálózati kapcsolat nélküli hoz- 
záférést és a felhasználói beállítások testreszabását bizto- 
sítja, ráadásul egyszerű, barátságos felületen. 


Architektúra 

A Project Central háromszereplős ügyfél-kiszolgáló archi- 
tektúrán alapul. Webes vezérlőit egy ActiveX vezérlőkészlet- 
tel valósították meg, melyek a Project Central adatbázis 
adatainak visszakeresésére és manipulálására, valamint 
üzenetek küldésére használhatók. A fejlesztők ezeket az 
összetevőket gazdag, interaktív, webalapú projektkezelési 
megoldások készítésére használhatják. 

A Project 2000 és Project Central architektúráját az alábbi 
ábra szemlélteti. A digital dashboard megoldásban a fel- 
használói felület az Outlook-ban található Outlook Today 
képernyőn megjelenített weblapba ágyazott Project Central 
vezérlőkből áll. A logikai és adatrétegek megegyeznek bár- 
mely más Project Central megoldásban találhatókkal. A Pro- 
ject Central Server-nek olyan webkiszolgálón kell futnia, 
melyet az ügyfélgépek egy URL-lel elérhetnek, a projektfáj- 
lokat pedig egy megosztásban kell tárolni, hogy az összes 
felhasználó elérhesse azokat. 

A projektek adatait a Windows biztonsági rendszere védi; a 
projektvezetőknek minden (Project-beli) erőforráshoz hozzá 
kell rendelni egy Windows felhasználói nevet, hogy bizto- 
sítva legyen a felhasználók automatikus hitelesítése, és 
hogy a megfelelő erőforrás információit lássák. 


User MC EtJta 
Interface Project 2000 


GSSEátEsatE 


Internet Explorer 
Microsoft Project 
(eTeleTes 


dugig 





Protocol Business ASP 
Objects Objects 
Microsoft Project Central Server 


HS 
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Tervezés és testreszabás 
Mivel a digital dashboard gyakorlatilag bármilyen információt 
tartalmazhat, a fejlesztőknek alaposan fel kell mérniük a fel- 
használók igényeit, és a vállalat információforrásait. Ez gyakran 
több erőfeszítést igényel, mint maga a digital dashboard alkal- 
mazás fejlesztése. A fő tervezési megfontolások a következők: 
mely Project Central lapokat kell megjeleníteni, milyen informá- 
ciót tartalmazzanak (és milyet ne) ezek a lapok, hogy fogják a 
felhasználók az adatokat hálózati kapcsolat nélkül elérni, és mi- 
lyen szinten szabhatják testre a digital dashboardot. A tervezés- 
kor a következő szempontokat célszerű szem előtt tartani: 
"0 Egyszerű nézet megjelenítése. Az egyszerű használat 
biztosítása érdekében csak alapvető projektinformáció- 
kat megjelenítő, kevés lehetőséget biztosító felhaszná- 
lói felületet tartalmazó kezdőlapot használjunk. Legye- 
nek rajta hivatkozások a bővített képességű felhaszná- 
lói felületet tartalmazó lapokhoz, és a Project Central 
teljes Internet Explorer ablakban való elindításához. 

Fontos információkra helyezzük a hangsúlyt. Használ- 

junk szűrőket, felhasználók által megadott kategóriákat 

és összegzéseket, hogy csak fontos információkat tar- 
talmazó üzeneteket juttassunk el az ügyfelekhez. 

-? Vonjuk össze a több forrásból származó információkat. 

A digital dashboard bármely Project Central weblapot képes 

megjeleníteni, de különösen a következő weblapok megje- 

lenítése lehet hasznos: 

8 Tasks/TasksPage.asp: A bejelentkezett felhasználó fela- 
datainak megjelenítése. 

0 StatusReports/StatusReports.asp: Állapotjelentések ké- 
szítése és kérése. 

8 Views/PortfolioView.asp: A bejelentkezett felhasználó 
számára elérhető projektek fontosabb adatainak megje- 
lenítése. A portfóliónézetből lehetőség van , mélyre ás- 
ni" az egyes projektekbe. Ez alapa  viewID alapján vá- 
lasztja ki a megjelenítendő nézetet. 

-b  Home/HomePage.asp: A feladatok, nézetek, állapotje- 
lentések információit, és a Project Central üzeneteket 
jeleníti meg. 

0 Views/WebClientView.asp: A Project Central-ban meg- 
adott feladat-kiosztási nézeteket jeleníti meg. Ez a lap is 
a viewID alapján választja ki a megjelenítendő nézetet. 


nm 


Digital dashboardok fejlesztése 

A digital dashboardok webes alkotóelemekre (Web Part), 
olyan többször felhasználható összetevőkre épülnek, melyek 
bármilyen webes információt tartalmazhatnak. Ezek egysze- 
rűbbjeinek létrehozása csak alapvető web (például HTML, 
DHTML, Active Server Pages, ActiveX) és Office programozási 
tudást igényel. A fejlesztők készíthetnek teljes funkcionali- 
tást biztosító digital dashboardokat, de akár egy webes alko- 
tóelem katalógust is, amiből a felhasználók kiválaszthatják a 
számukra szükségeseket, és saját digital dashboardokat ké- 
szíthetnek. A Web Part Builder használatával létrehozhatók 
olyan kifinomult alkotóelemek is, melyek képesek együttmű- 
ködni a Microsoft Office 2000, a Microsoft Exchange Server, 
és a Microsoft SOL Server által biztosított eszközökkel. 

A Digital Dashboard Resource Kit 2.0 (DDRK) a dashboard min- 
ták és az azonnal beépíthető összetevők mellett tartalmazza a 
Web Part Builder-t, és a digital dashboardok készítéséhez és 
üzembehelyezéséhez szükséges összes eszközt is. A DDRK előre 
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elkészített webes alkotóelemeket is biztosít, melyek felhasznál- 

hatók az egyedi digital dashboard megoldások készítésekor. 

A projektinformációk megjelenítésének pontos szabályozá- 

sához egyedi Project Central webes alkotóelemek készíthe- 

tők, és/vagy a projekt információk digital dashboardban 

való megjelenítési módjának szabályozására megváltoztat- 

ható a webes alkotóelem ContentLink lekérdezés sztringje, 

vagy átszerkeszthetők az általa meghívott Project Central 

ASP-k. A következő részekben az alábbiakkal foglalkozunk 

részletesen: 

"b Egy Project Central webes alkotóelem készítése 

-0 A ContentLink tulajdonság és lekérdezés sztring para- 
méterei 

"0 A Project Central ASP-k 

"0 Fejlettebb webes alkotóelemek fejlesztése 


Egy Project Central webes alkotóelem készítése 

Ebben a részben a Project Central webes alkotóelemek készíté- 

sének lépéseit ismertetjük. Ne feledjük, hogy a megfelelő mű- 

ködéséhez szükséges egy intranetünkön található kiszolgálóra 
telepített Project Central, és minden felhasználónak, akinek 
digital dashboardja lesz, hozzáféréssel kell rendelkezni ehhez 

a kiszolgálóhoz, és érvényes Project Central ügyfélhozzáférési 

licenszének kell lennie. Emellett a Project Central Server-nek a 

Windows NT hitelesítést kell használnia, és minden felhaszná- 

lónak rendelkeznie kell egy érvényes NT-s azonosítóval, és az 

annak megfelelő Project Central erőforrásazonosítóval. 

Project Central webes alkotóelem készítéséhez: 

-0 Nyissuk meg a digital dashboardot vagy a webes alko- 
tóelem-katalógust, melyben a Project Central webes al- 
kotóelem lesz. 

A Kattintsunk a Content-re, 

"0 Majd a Create a New Web Part hivatkozásra. 

"0 Adjunk nevet a webes alkotóelemnek 

0 Jelöljük ki az elhelyezkedését a digital dashboard lapon. 

"b A Content Link szövegdobozba írjuk be az URL-t és a 
lekérdezés sztringet (lásd később). 

"? Jelöljük meg a jelölőnégyzetet a webes alkotóelem tar- 

talmának elkülönítéséhez. 

Állítsuk be a webes alkotóelem egyéb tulajdonságait. 

Kattintsunk az OK-ra. 

Nyissuk meg a digital dashboardot, melybe a webes al- 

kotóelemet mentettük. 

A Project Central webes alkotóelemei függetlenül, vagy kata- 

lógus részeként is üzembehelyezhetők. A webes alkotóelemek 

katalógusa egy olyan speciális célú digital dashboard, mely- 
ből a felhasználók kiválaszthatják az általuk elképzelt egyedi 
digital dashboardhoz szükséges webes alkotóelemeket. 

A ContentLink tulajdonság és lekérdezés sztring para- 

méterek 

A legegyszerűbb webes alkotóelem egy meglevő Project Central 

lapra mutat. Ez esetben csak a ContentLink tulajdonság szük- 

séges a Project Central web megjelenítéséhez. A fejlesztők a 

ContentLink lekérdezést a Project Central információk számos 

megjelenítési lehetőségének szabályozására használhatják. 

A Contentlink tulajdonság az alábbi hat elemből áll: 

"0 Microsoft Project Central Server: az intranetes webhely 
címe, ahová a Project Central telepítve lett. 

"0 Virtuális könyvtár a kiszolgálón: a virtuális könyvtár 
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8 Project Central kezdőlap: a lekérdezés sztring paramé- 
tereinek helyes feldolgozása érdekében a kezdőlap 
mindig a default.asp legyen. Egy másik lap digital 
dashboardban való megjelenítéséhez irányítsuk át a 
felhasználót, a DefPage- lekérdezés sztring paramétert 
használva a lap nevének megadására. 

8 Paraméterek a testreszabáshoz: Lekérdezés sztring érté- 
kek, melyek testreszabják a Project Central felhasználói fe- 
lület megjelenítési módját. Két lehetséges paraméter: 

8 — NoMenu-1]0 
Be- (0) vagy kikapcsolja (1) a Project Central fel- 
ső menüjét. Az alapértelmezett ASP lap lekérde- 
zés sztringjében kell lennie. 

-b — SimpleUI-1]0 
Be- (0) vagy kikapcsolja (1) a Project Central felső 
szalagcímét és megszünteti a baloldali, hivatkozá- 
sokat tartalmazó keretet. Az alapértelmezett ASP 
lap lekérdezés sztringjében kell lennie. 

"8 A megjelenítendő Project Central lap: Ez a lap van 
megadva a webes alkotóelem nézetben. A lap a , Def- 
Page-"-el kezdődő lekérdezés sztringben van megadva. 
Az érték bármely Project Central ASP neve lehet. 

"B Laplekérdezés sztring paraméterek: Ezek a lekérdezés 
sztring paraméterek szabják testre az egyes Project Central 
lapok megjelenítési módját. Három lehetséges paraméter: 
b GanttView 1 

Csak a TasksPage-re érvényes, megadja, hogy a 
Gantt diagram nézet legyen-e megjelenítve. Ha ez a 
paraméter létezik, Gantt diagram nézet jelenik meg. 
b — TimesheetView-1 
Csak a TasksPage-re érvényes, megadja, hogy a 
Timesheet (időtábla) nézet legyen-e megjelenít- 
ve. Ha ez a paraméter létezik, Timesheet nézet 
jelenik meg. 
A —— ViewID- cViewID5 

Ez a PortfolioView vagy WebClientView lapon megjelenítendő 

nézet egyedi azonosítója. Ez a paraméter használható a Pro- 

ject Central adatbázisának MSP WEB VIEW REPORTS táblájá- 
ban definiált bármely nézet megjelenítésére. Ha a Portfolio- 

View lapot használjuk, csak a portfóliónézetek érvényesek, és 

a WebClientView lap használatakor, a viewID-nak a szokásos 

(nem portfólió) Project Central nézetnek kell lennie. 

A következő példákban a ContentLink lekérdezés sztring 

néhány szokványos változata látható: 

"b Az egyéni Gantt diagram nézet szabványos Project 
Central felület nélküli megjelenítéséhez: 


http: //myprojectcentralserver/ProjectCentral/ 
GW default.asp?noMenu-lősimpleUI-1 
 §defPage-rTasks/TasksPage.asp?GanttViewz-l 


"8 Atimesheet (időtábla) nézet szabványos Project Cent- 
ral felület nélküli megjelenítéséhez: 


http: //myprojectcentralserver/ProjectCentral/ 
4 default.asp?noMenu-lásimpleUI-1 
4 sdefPage-Tasks/TasksPage.asp?TimesheetView-1 
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"B A szokásos feladatkiosztási nézet szabványos Project 
Central felület nélküli megjelenítéséhez: 


http: //myprojectcentralserver/ProjectCentral/ 
4 default.asp?noMenu-lssimpleUI-1 


4  §SdefPage-Views/WebClientView.asp 


"B A portfóliónézet 3-as számú nézetének szabványos 
Project Central felület nélküli megjelenítéséhez: 


http: //myprojectcentralserver/ProjectCentral/ 
4  default.asp?noMenu-lásimpleUI-1 


4 SdefPage-Views/PortfolioView.asp? viewID-3 


A Project Central ASP-k 

A webes alkotóelemben megjelenített információk megjele- 
nítési módjának további testreszabásához átszerkeszthetők a 
Project Central ASP lapok. Például feladatlapok, Project Cent- 
ral honlapok és nézetlapok digital dashboardban való megje- 
lenítésekor megszüntethetjük a szükségtelen elemek megje- 
lenítését, hogy hatékonyabban használhassuk ki a rendelke- 
zésre álló felületet. A DDRK-ban található ilyen minta ASP 
lap. Eredeti Project Central ASP lap átszerkesztése előtt min- 
dig készítsünk róla biztonsági másolatot! 

A következő példában bemutatjuk, hogyan biztosíthat a Pro- 
ject Central PortfolioView.asp lap néhány viszonylag egyszerű 
módosítása egy webes alkotóelemben használható sokkal ki- 
sebb felhasználói felületet. Az eredményként létrejövő lap, a 
MinPortfolioView.asp, a DDRK-ban is megtalálható. 

A szokásos Project Central portfóliónézetet a PortfolioView- 
.asp jeleníti meg. Ahogy a következő ábrán is látható, ez tar- 
talmaz olyan magyarázó szövegeket is, melyek érdektelenek 
a digital dashboardot használóknak. 


Wiew Your Portfolto 





See summary information about your por 





Your portfolia contains a hat of projects th sott Pro jdrminutrátor has given you permissson to see. 


from the portfoko, you can select a single project tó see more deti -h as the projects tasks and resöuross. 


Grouohv: [NT] Thebes [Mo TI mente [Mn z] 
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5 Változtatás nélküli PortfolioView.asp 


Ha a portfóliónézet megjelenített ASP lapjából kiszedjük 
ezt a szöveges információt, értékes digital dashboard felü- 
let takarítható meg. Az eredmény az alábbi ábrán látható. 


View Your Portfolio £hoose a view: [cost z 
Group hy: (None z] Then bx: [none z] Then by: [none z 


[ Aazoomin [ AZoomaut [7 Goto selected project [KÉJ ven in Microsoft Broject ] 
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5 PortfolioView a szükségtelen elemek eltávolításával. 


E tömörebb nézet elkészítéséhez a PortfolioView.asp lapnak 
csak két részét kell megváltoztatnunk: a cDIV: címkéket, 
melyek szöveg sztringeket írnak ki a képernyőre, és a né- 
zetválasztó függvényt, mely lehetővé teszi a felhasználónak 
a megjelenített oldal kiválasztását. 
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Az eredeti PortfolioView.asp-ben a 60. sornál kezdődő rész- 
ben a legtöbb kód szöveg sztringek (oStrings.GetString) 
kiírására szolgál, melyeket a Project Central portfóliónézete 
tartalmaz: 


LKDIV ID-"idSectionHeader" LASS-"SectionHeaderiInfő 
4 STYLE-"line-height: 1.6em;"2 
cszoStrings.GetString( 

4 IDS VIEWS PORTFOLIO HEADER TEXT).bold()$2 
€/DIV3 

£/DIV2 

CKDIV ID-"idBanterTextSection" CLASS-"Workspace" 
4 STYLE-"width: 100£; overflow: hidden;": 
CKDIV ID-"idText" CLASS-"SectionHighlight" 

4 STYLE5"font-size: 70$; padding-left: 12; 

4 padding-top: 8; padding-bottom: 16; 

4 width: 1008;"5 

LKDIV CLASS-"Text" STYLE-"margin-bottom:8;"5 
cszoStrings.GetString( 

8 IDS VIEWS PORTFOLIO BANTER TEXT1)32€/DIV3 
LKDIV CLASSzZ"Text"5 

cszoStrings.GetString( 

4 IDS VIEWS PORTFOLIO BANTER TEXT2)t2€/DIV5 
£/DIV5 

£/DIV2 


Az átszerkesztett ASP lapban a fenti kódrészlet a követke- 
zőre lett kicserélve: 


£/DIV3 


CcxDIV ID-"idBanterTextSection" 
U CLASSz"Workspace"53€/DIV5 


Az átszerkesztett lapból az összes ASP-ből beillesztett szö- 
veg, és néhány, DIV címkéken belüli rész el lett távolítva. 
Figyeljük meg, hogy bár az idBanterTextSection DIV címke 
megmaradt, nem tartalmaz szöveget. Erre az objektumra 
később utalás van az ASP lapban, ezért az oldal megjelení- 
tésekor problémákat okozna eltávolítása. 

Az ASP második megváltoztatandó része a nézetválasztó 
függvény, mely a Choose a view lista (portfóliónézet lap 


jobb felső részében való) megjelenítéséért felelős. 


window.location.href - 
HW "PortfolioView.asp?c$zoPJSession.oUser. 


4 GetURLString()$5 viewID-"tchooseView.value; 


Ha nem változtatnánk meg, ez a vezérlő biztosítaná a digi- 
tal dashboard felhasználónak az új nézet legördülő listából 
való kiválasztását, és az oldal a szokásos portfóliónézetre 
váltana. Ezt a problémát így oldjuk meg: 


window.location.href 5 
u "MinPortfolioView.asp?c$zoPJSession.oUser. 


G GetURLString()32 viewID-"tchooseView.value; 
Ezt a példát alapul véve testreszabhatók a feladatlapok, a Pro- 


ject Central honlapok és a nézetek lapjai, hogy a webes alko- 
tóelemek által felhasznált képernyőterület a lehető legjobban 
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kihasználható legyen. Hogy a webes alkotóelem tartalmazza a 
megváltoztatott lapot, változtassuk meg a DefPage- lekérde- 
zés sztring paramétert úgy, hogy az átszerkesztett/átnevezett 
ASP lapra mutasson. A megváltoztatott lap ugyanazokra a 
. viewld paraméterekre fog reagálni, mint az eredeti. 

A Project Central-nak sok más lehetséges alkalmazása lehet egy 
digital dashboardon belül, melyek mindig a felhasználók igé- 
nyeihez igazodnak (például csak az üzenetek, vagy csak a 
feladatok rész megjelenítése) . A szokásos honlapról leszedhetők 
információs részek is, hogy csak összevont információk jelenje- 
nek meg (például az új üzenetek, új feladatok és a késésben le- 
vő feladatok száma) egy igen tömör webes alkotóelemben. 


Egy felhasználó által beállítható webes alkotóelem lét- 
rehozása 

Az előző példákban egy adott Project Central kiszolgálót kel- 
lett megadni a webes alkotóelem ContentLink-jében. Erre 
azonban a felhasználók általában nem képesek, főleg akkor 
nem, ha a rendszergazda nem engedélyezi nekik, hogy a di- 
gital dashboard Content hivatkozásának használatával köz- 
vetlenül elérjék a webes alkotóelemben a ContentLink tulaj- 
donságot. Az egyik lehetséges megoldás egy felhasználó által 
beállítható webes alkotóelem alkalmazása, mely lehetővé te- 
szi, hogy a felhasználó magából a webes alkotóelemből fris- 
sítse a ContentLink-et. Ez a megoldás két lépésből áll: (1) egy 
üres ContentLink-et tartalmazó új webes alkotóelem létreho- 
zása, és (2) a szkriptelt beágyazott tartalom beágyazása, ami 
lehetővé teszi a felhasználónak a ContentlLink frissítését. 


Az üres ContentLink 

Egy digital dashboard minden webes alkotóeleme a benne 
található ContentLink információit próbálja megjeleníteni. 
Ha nincs ContentLink, a webes alkotóelem a benne talál- 
ható beágyazott tartalom (EmbeddedContent) adatait jele- 
níti meg. Amikor egy felhasználó által beállítható Project 
Central webes alkotóelemet adunk a digital dashboardhoz, 
a webes alkotóelem a beágyazott tartalmat fogja mutatni, 
mert a Contentlink üres. Ez látható az alábbi ábránkon: 


Enter the Microsoft Project Central base URL: 


(e.g. httpr//ServariamazPrajectcentral) 





G Ho 
€ Portfoliv Tracking Part 


OK 


paga Part C 7ack st Part 


€ Portfulio Cost Part 











o A Project Central webes alkotóelem ContentLink nél- 
küli megjelenítése. 


Miután a felhasználó beírja a megfelelő Project Central 
URL-t, kiválasztja a kívánt alkotóelem típust, és az OK-ra 
kattint, a szkript frissíti az alkotóelem ContentLink-jét, és 
a digital dashboardot, hogy az újonnan beállított alkotó- 
elemet mutassa. A szkript a digital dashboard összetevőt 
(Digital Dashboard Component) használja a webes alkotó- 
elem tulajdonságainak frissítésére. 

Egy digital dashboardra sok ilyen, felhasználó által beállítha- 
tó webes alkotóelem helyezhető, melyek mindegyike akár 
más-más Project Central kiszolgálóra mutathat, és mindegyik- 
re más-más stílust adhat meg. Ily módon egyetlen webes al- 
kotóelem lehetővé teheti a felhasználóknak, hogy több webes 
alkotóelemet készítsenek a digital dashboardon belül. 
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A beágyazott tartalom 

A példánkban használt beágyazott tartalom helytakarékos- 
sági okokból a következő címen található [1] pcentral.htm 
fájlban olvasható. 


A webes alkotóelem kibővítése 

Ugyanezt a példát követve, a webes alkotóelem könnyedén 
kibővíthető, hogy több választógombot és alkotóelem-tí- 
pus funkciót tartalmazzon. Minden egyes alkotóelemnek 
saját alapértelmezett stílus-tulajdonságai vannak, melye- 
ket a szkriptben lehet beállítani, és igény szerint az adott 
alkotóelem-alkalmazáshoz szabni. 

A , WPA, " sztring együttes használata a szkript funkciók ne- 
vében és a HTML elemek nevében biztosítja, hogy a név egye- 
di marad, amikor a felhasználó egynél többet helyez ezekből 
a webes alkotóelemekből ugyanarra a digital dashboardra. Ha 
a Project Central kiszolgáló URL-je megváltozik, a felhaszná- 
ló megváltoztathatja a webes alkotóelem tulajdonságait úgy, 
hogy az új URL-re mutasson. Ehhez a digital dashboard felső 
részén található Content hivatkozásra kell kattintania, és ki- 
választani a megváltoztatandó webes alkotóelemet. A kivá- 
lasztott webes alkotóelem Advanced Properties lapján a fel- 
használó törölheti a Get content from the following link tu- 
lajdonság tartalmát, és visszavonhatja az erre vonatkozó je- 
ltölőnégyzet megjelölését, a digital dashboardra visszatérve 
pedig átállíthatja a webes alkotóelem beállításait. 

Ha a fejlesztő nem ad rá lehetőséget, a felhasználó nem 
férhet hozzá a webes alkotóelemhez, vagy nem tudja meg- 
változtatni annak tulajdonságait. Ez esetben egy lehetőség 
marad: törölni a webes alkotóelemet a digital dashboard- 
ról, majd újra hozzáadni az eredetit a katalógusból. 


[1] http: hnet.n mia.ni n ntral.htm 


http://www.microsoft.com/solutions/ki 
DigitalDashboard.htm 
A DDRK az alábbi helyről tölthető le: 8 ere 


solutions/km/ddrk.htm 


A Project Central tanulmány az alábbi helyen található: 


http://www.microsoft.com/office/project/ProCenWP.htm 
A Project 2000 Resource Kit itt található: 
http://www.microsoft.com/office/project/prk/2000/ 
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Ingyenes levelezési listáinkra feliratkozás a 
http://www.netacademia. net/lyris.asp címen. 


K: Miért nem sikerül használnom a Terminal Services távirá- 
nyítási (Remote Controll) funkcióját? Már minden szükséges 
jogot megadtam, de a menüpont továbbra is szürke. Tipp? 
V: Nem tipp, tapasztalat: ez egy ismert , feature". Csak ak- 
kor nem szürke a menüpont, ha Terminal ablakból próbálod. 
Az interaktív felhasználónak mindig szürke. Hogy miért? 
Csak. Ha bejelentkezel ÉS beterminálsz rendszergazdaként, 
csodák csodája, menni fog. 

Forrás: NetAcademia Windows 2000 lista 


K: Lehet valahogy automatizálni a Map Network Drive-ot in- 
duláskor? Azt szeretném ha nem kérné a jelszót miután be- 
léptem a gépre, hanem automatikusan felhúzná egy meghaj- 
tónak a kívánt UMWservertshare-t. Próbálkoztam a registryben, 
és a HKEY CURRENT USERWetwork) mappelni kívánt meg- 
hajtó alatt meg is találtam amit kerestem, de nem tudtam 
úgy beállítani hogy ne kérjen jelszót. 

V: Megoldási javaslatok (teljes körű lista): 

1. Megfelelő tartományi tagsággal, megfelelő felhasználói 
fiókkal, megfelelő jogosultság birtokában természete- 
sen nem kell jelszót megadni 

2. Ha már egyszer a gép nincs tartományban, legalább a gépe- 
ken lévő felhasználók neve és jelszava legyen azonos 

3. Engedélyezd a megosztó gépen a guestet (ellenjavallt) 

4. A map parancsban add meg a jelszót: 
net usetservertshare password /user:domain/username 

Forrás: NetAcademia Windows 2000 lista 


K: Hogyan tudnám felbecsülni hálózatunk biztonsági felké- 

szültségének fokát? És ha ez megvan, hogyan tovább? 

V: Innen, a távolból igen nehéz erre a kérdésre válaszolni, 

hisz a biztonság a szoftvereken kívül rengeteg emberi ténye- 

zőtől is függ, például szorgalom és lustaság, ravaszság és bu- 

taság stb. Éppen ezért e kérdés megválaszolására , felkértük" 

a Microsoft biztonsággal foglalkozó részlegének munkatár- 

sait, akik kétszer tíz pontba foglalták a biztonság alaptörvé- 

nyeit. A ,The Ten Immutable Laws of Security" eredetije az 

alábbi címen olvasható [1]: 

1. Ha egy rosszfiú rávesz, hogy futtasd az ő programját a 
gépeden - az nem a te géped többé. 

2. Ha egy rosszfiú meg tudja változtatni gépeden az op- 
rendszert - az nem a te géped többé. 

3. Ha egy rosszfiú fizikailag hozzáfér a gépedhez- az nem 
a te géped többé. 

4. Ha megengeded, hogy rosszfiúk programokat töltsenek fel 
a webkiszolgálódra - az többé nem a te webkiszolgálód 

5. A gyenge jelszavak és az erős biztonság ütik egymást 

6. Egy gép csak annyira biztonságos, mint amennyire 
megbízható a rendszergazdája 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
2001. 02. 


Dupia kv v Kérdezz, Felelek! 


7. A titkosított adatok csak annyira megbízhatók, 
amennyire a titkosítási kulcs 

8. Egy kiöregedett víruskereső alig jobb, mint ha egyálta- 
lán nem használunk víruskergetőt 

9. Teljes névtelenség nincs. Sem a valós életben, sem a weben 

10. A technológia nem csodaszer 


A ,The Ten Immutable Laws of Security Administration" 

eredetije az alábbi címen olvasható [2]: 

1. Senki sem hiszi el, hogy rossz dolog történhet vele, 
amíg meg nem történik 

2. A biztonság csak akkor tartható be, ha a biztonságos 
megoldás egyben használható megoldás is 

3. Ha nem használod a biztonsági javításokat (hotfix) 
előbb-utóbb nem te leszel a rendszergazda 

4. Semmi értelme biztonsági hotfixeket telepíteni egy tel- 

jesen magára hagyott gépre 

A biztonság elérésének egyetlen módja az örök éberség 

Tuti, hogy van valaki, aki kíváncsi a jelszavadra 

A legbiztonságosabb hálózat a felügyelt hálózat 

A hálózat védhetősége fordított arányban áll bonyolult- 

ságával 

9. A biztonság nem a kockázatok elkerülésének, hanem a 
kockázatok kezelésének tudománya 

10. A technológia nem csodaszer 

A [3] címről letölthető egy képernyővédő, ami ezeket a tör- 

vényeket sulykolja a fejünkbe :) 

Forrás: NetAcademia Security lista 


et 


K: Van valami lehetőség arra, hogy a 6.5-ös MS-SOL Servemél én 
adjam meg a tempdb méretét? Ugyanis a 6.5-ös szerverünket 
adatbázisostul szeretném upgradelni 7.0-ra, de a DTS azzal fi- 
gyelmeztetéssel áll le, hogy amíg nem növelem meg legalább 10 
megára a tempdb méretét, addig nem hajlandó megmoccani sem 
(a 6.5-ös telepítésnél 2 MB-os mérettel jött létre a tempdb, és 
ennek méretét sehogysem tudom feljebbtornászni). 

V: A tempdb default-ban a master device-on van. Előbb a 
master device méretét növeld meg: Enterprise manager, Da- 
tabase devices, master, jobbkatty, edit. Majd a databases, 
tempdb jobbkatty, edit, expand, Data device: master kivá- 
laszt (beírhatod a méretet), expand now. Lehet szebben is, 
jobban is, de upgrade-hez ez is jó. 

Forrás: NetAcademia SOL 2000 lista 


K: Átállítottam az SOL Server 7.0 alatti számítógép nevét, de 
sajnos nem szerette. Ezt mondta: 

nYour SOL Server installation is either corrupt or had been 
tampered with (unknown package id) Please rerun setup." 
Elég barátságtalan. Most mit csináljak? Azt kipróbáltam, 
hogy ha visszanevezem a régi nevére, megint megy, de ne- 
kem az új név kellene! 
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V: Futtasd le az SOL Server 7.0 Setupot az eredeti CD-ről. Ne 
izgulj, nem fogja agyonvágni az adatbázisaidat, csak átírja a 
Master adatbázisban amit át kell, hogy elinduljon az új név- 
vel. Vagy futtasd le az alábbi két tárolt eljárást: 


sp. dropserver Cold names 
go 
sp addserver Cnewnamer, local 


go 
Forrás: NetAcademia SOL 2000 lista 


K: Azt kellene megoldanom, hogy amikor Internet Explorer- 
ben egy HTML űrlapon cEnter:-t ütnek, akkor ne POSTolód- 
Jon el, hanem csak ugorjon a bevitel a következő mezőre, 
mint ahogy ez a Netscape esetében is történik. 

V: Vagy le kell nyelni az cEnter: lenyomásakor keletkező On- 
KeyPressed eseményt, azaz le kell kezelni az eseményt, és nem 
csinálni benne semmit, ha a leütött gomb cEnters volt vagy 
elkapod az OnSubmit eseményt, és nem csinálsz benne sem- 
mit (FORM OnSubmit-return true vagy false;). Ilyenkor nem a 
submit gomb ,,viszi el" a lapot, hanem egy egyszerű BUTTON, 
és annak az OnClick eseményében meghívod a form.Submit- 
Form() eseményt, azaz leszimulálod a valódi submit-ot. 
Forrás: NetAcademia MsDev lista 


K: Mondjátok meg legyetek szívesek, hogy mi a hiba a kö- 
vetkező VB 6 kódban, mert mindig elszáll: 


Dim rs As ADODB.Recordset 
Do While Not rs.EOF And rs!Name c5 "gronuj" 
rs.MoveNext 


Loop 


V: Az, hogy - például - a C nyelvvel ellentétben a VB ki pró- 
bálja értékelni az AND jobb oldalát is, annak ellenére, hogy 
már logikailag nem teljesülhet a feltétel, amikor EOF-on 
van. Így EOF esetén már nincs recordset, azaz már nincs 
rs!Name sem. Tehát ebben az esetben hibaüzenettel elszáll. 
Helyesen - pontosabban működőképesen: 


Dim rs As ADODB.Recordset 

Do While Not rs.EoF 
if rslName c5 "gronuj" Then Exit Do 
rs.MoveNext 

Loop 


Forrás: NetAcademia MsDev lista 


K: Hogy lehet elérni, hogy a szépen megírt, és elküldött üze- 
netet csak 1 vagy 2 perc múlva küldje ki az Exchange Server? 
Ez ahhoz kellene, hogy ha valaki meggondolja magát, akkor 
azt még minden körülmények között vissza lehessen hívni. A 
Recall Message nem jó, mert ha a levél már kiment, eléggé 
kétesélyes a működése: vagy igen, vagy nem. 

V: Outlook 2000-nél az éppen írt levél beállításai között 
találjuk a ,Do not deliver before" vagy , Kézbesítés legko- 
rábban" mezőt. Kicsit macerás minden levélnél kitölteni, 
de ez az amit keresel. 

Forrás: NetAcademia Exchange lista 
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K: Jobb dolgom nem lévén, KMS-t telepítettem egy Pilot 
rendszerben Exchange 5.5 SP4-re. A szolgáltatás szépen fel is 
vándorol, a szükséges password-t úgy döntöttem, hogy majd 
megjegyzem. Egy kimondottan Exchange-t telepítő user-rel 
telepítettem a komponenst. Telepítés alatt az Exchange ser- 
vice-k nevében települt. Ahogy kell, Manual-ban is van a ser- 
vice, a Startup parameter megadása után be is indul, csak 
nem érem el az Organization ISite IConfiguration alatt levő CA 
objektumot. Dupla kattyra előjön ugyanaz az ablak ami a tu- 
lajdonságokra is. Bent van az éppen bejelentkezett felhasz- 
náló neve (READ-ONLY) és kéri a KMS jelszavát. Ezt begépel- 
ve not working properly. Persze próbáltam már a bejelentke- 
zett, a telepítő, a service account jelszavakat is - hiába. Ka- 
pok egy hibaüzenetet, hogy bizonyára elgépeltem, de ez le- 
hetetlen. (CRTL4-C; CTRL4-V) Gondoltam, biztos nincs joga an- 
nak a felhasználónak piszkálni a CA objektumot, próbáltam 
az összes szóba jöhető felhasználóval, de az eset teljesen 
azonos, full exchange rendszergazda esetén is. 

Mellesleg nem értem, hogy ha kislemezre van kiírva a jelszó, 
amikor megszeretném nyitni a CA-t miért nem nézi a lemezt 
és miért várja hogy begépeljem a jelszót, amit nem is tudha- 
tok, mert a lemezre történő írás során nem mutatja meg a 
DISPLAY-en. Persze egyszerűen ki lehet deríteni, mert a pwd 
kiterjesztésű file notepad-ban simán olvasható. :-) De sajnos 
nem működik így sem, próbáltam. A probléma csak az, hogy 
CA administrator-t csak akkor tudom állítani, ha bejutottam. 
Még egy kérdés, ez itt most miért is CA?? Nem KM-nek kéne 
lenni?? Nincs is CA telepítve a gépre. Nem értem. 

V: A KMS egy kulcshitelesítő és osztogató komponens, egy 
Certificate Authority. Ezért jogosan ez a neve annak ellené- 
re, hogy ez nem a Windows saját CA-ja. A KMS telepítéséhez 
mintegy ezer jelszó tartozik, s itt éppen az ezeregyediket kell 
begépelni, ami kezdetben , password". Mindenkinek azt ja- 
vaslom, hogy papírral és ceruzával alaposan felszerelkezve 
álljon neki a KMS telepítésének, és ne csak a jelszavakat 
vésse fel, hanem a szerepüket is: szolgáltatásindító jelszó, 
bulk enrollment, token ide-oda: bonyolult. És akkor még 
nem is beszéltünk az ügyféloldali jelszavakról. A KMS hasz- 
nálata a felhasználók oktatását igényli. 

Forrás: NetAcademia Exchange lista 


[1] http://www.microsoft.com/technet/security/10imlaws.asp 
10salaws.asi 


[2] http://www.microsoft.com/techni 


DUPLA 


[3] http://www.microsoft.com/Downloads/Release.asp?ReleaseID-26684 
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Amikor a telefon több mint száz évvel ezelőtt újdonságnak 
számított, az emberek nem igazán tudták, hogy mit kezdje- 
nek vele. Mire is volt jó? 

Úgy tűnt, nem sok mindenre. A Western Union szerint nem se- 
gített a táviratok gyorsabb átvitelében, ezért nem is vették 
meg a találmányt. (Ez 1876-ban történt, illetve NEM történt.) 
sg Állítólag még a telefon feltalálója, 
Alexander Graham Bell sem tudta, 
mire lesz jó az eszköz, szerinte ugya- 
nis a telefon a mondanivaló szét- 
osztására, terítésére szolgált volna. 
Bell tévedése érthető, ha figye- 
lembe vesszük, hogy akkoriban 
1] még nem voltak autók, és ezért a 





legtöbb ember nem messze otthonától dolgozott. Ha vala- 
ki beszélni akart egy barátjával, egyszerűen átment a szom- 
szédba. Ki gondolhatta volna, hogy a telefon legfőbb fel- 
használása a két ember közti kommunikáció lesz? 


A történelem talán ismétli önmagát. Bár az elektronikus le- 
velezés gyorsan terjed, az emberek többsége még mindig 
úgy gondol az Internetre, mintha az csupán weblapok hal- 
maza lenne. Lehet, hogy ez Bell 120 évvel ezelőtti tévedé- 
sének megismétlődése? Az Internet valóban forradalmi in- 
formációközzétételi eszköz, de a hálózatban sokkal na- 
gyobb lehetőségek rejlenek... 

Az elektronikus levelesládákat elözönlik az e-mailek. Az 
elektronikus csevegés és az elektronikus közösségekben va- 
ló részvételi arány növekszik. A csevegés elbűvölő jelenség: 
képzelt ,szobákban" zajlik, ahol hasonló gondolkodású em- 
berek gyűlnek össze. Általában olyan emberek váltanak üze- 
neteket, akik még sosem találkoztak személyesen. 

Egy telefonbeszélgetéssel összehasonlítva a csevegés techni- 
kai minősége gyengének tűnik, korlátai ellenére népszerűsé- 
ge mégis egyre nő, mert nagyon erős az igény arra, hogy má- 
sokkal - akár idegenekkel is - kapcsolatokat alakítsunk ki. 
Gépelnünk kell az üzeneteket, ami kényelmetlenséggel jár, 
de megszerkeszthetjük mondandónkat, mielőtt válaszol- 
nánk valamire, s ez kompenzálja a hátrányokat. Az a cseve- 
gési változat, mely lehetővé tette a hang-kommunikációt, 
hamar elbukott. Szerintem az emberek zavarba jönnek, ami- 
kor szépen és érthetően kell beszélniük. 

A csevegőszobák tele vannak mindenféle emberrel -otthon- 
ról élnek társadalmi életet - egyszerűen, biztonságosan 
kommunikálnak, és anélkül, hogy akár fel kéne öltözniük. 
Az emberek a kibertérben az önkifejezés új útjait keresik." 
Bár én nem töltök sok időt ilyen csevegőszobákban, isme- 
rek olyanokat, akik igen. Egyikük egy barátom, akinek a Be- 
anie Baby-k a szenvedélye. Jelentős időt képes eltölteni az- 
zal, hogy róluk cseveg, és csereberéli őket. Egy Microsoftos 
vezető, aki az online szocializációhoz tervez eszközöket, el- 
kezdte tanulmányozni a csevegőszobákat, és megdöbbené- 
sére hamarosan napi két-három órát csevegéssel töltött. 
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Szocializálódás 
az Interneten 


Amikor belemelegedsz, nagyon is valós kapcsolataid szü- 
letnek" - mondta. 
A névtelenség a legtöbb csevegőszobában megengedett. 
Néhányban az is lehetséges, hogy minden alkalommal más 
nevet használjunk, de ez a gyakorlat gyakran durva és meg- 
gondolatlan viselkedéshez vezet, mert az antiszociális maga- 
tartásnak csak kevés következménye van. Ha az embereknek 
állandó nevet kell használniuk - még ha kitaláltat is, például 
.Sissy" vagy ,Metal X" -, általában mögötte megjelenik a sze- 
mélyiségük. Ösztönösen kialakítanak magukról egy képet, 
amelyet aztán meggondolt magatartással tartanak fenn. 
A csevegés, és az Internetes társadalmi élet egyéb for- 
máinak robbanásszerű fejlődése várható. , Virtuális világok" 
jönnek létre, melyekben a résztvevők kiválasztanak maguk- 
nak egy virtuális személyiséget (arccal, ruházattal). Ezek a 
megtestesülések (angolul avatar-ok — a ford.) ritkán hason- 
lítanak az egyénre. Az emberek közel mehetnek egymáshoz 
és beszélgethetnek, de visszahúzódhatnak egy sarokba is, 
hogy egyedül legyenek, vagy hallgatózzanak. 
Bútorok és más objektumok is vannak a virtuális szobákban, 
átböngészhetjük például egy iratszekrény tartalmát, vagy 
leülhetünk egy fotelba. Az objektumok pedig ott lesznek 
akkor is, amikor egy héttel később visszatérünk az adott kö- 
zösségbe, és a szoba talán ugyanúgy fog kinézni, mint ami- 
kor otthagytuk, bár más ,emberek" lesznek ott. 
A virtuális világok lehetőségeinek felfedezése még csak most 
kezdődik. A kísérlet, melyet mi végzünk, a Fred Hutchinson 
Cancer Research Center-ben, Seattle-ben folyik. 
A fejlesztés alatt álló , HutchWorld," - amely egyelőre nem 
elérhető a nyilvánosság számára - tükrözni fogja az eredeti 
épület, és a benne dolgozók/élők életét. (A http://www.re- 
search. microsoft.com/vwg/ címen megtalálható minden infor- 
máció a HutchWorld-ről. Innen letölthető a virtuális objektum 
bemutató videója is, amely sajnos 40 megabájtos, így csak 
igen türelmes embereknek ajánlott...) Olyan elrendezésű lesz 
az objektum, mint az igazi épületegyüttes. A HutchWorld- 
nek van ,házfelügyelője", aki megválaszolja a kérdéseket, 
egy üzenetterülete, ahol a közösség más tagjainak lehet 
üzenetet hagyni, sőt, még egy olyan helye is, ahol ajándé- 
kokat lehet hagyni, virtuális virágok és csokoládé (képek) 
formájában (a szándék a fontos, nem a tárgy). A későbbiek- 
ben, ha már stabil rendszerrel. EmEyztettütetiTTT 
rendelkezünk, meg fogjuk JKOGJEZIZE EEG 
nyitni a nagyközönség előtt, 
hogy bárki részt vehessen az 
ott induló tanfolyamokon, 
szórakoztató programokon. 
Hogy mire is jó az Internet? 
Társadalmi környezet, akár- 
csak a telefon. Gazdagítja kommunikációs lehetőségeinket: 
a virtuális valóság a való világra is jelentős hatással lesz. 
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TechNet szemináriumok a Microsoft Magyarország szervezésében! 
Helyszín: BUDAPEST, Lurdy Ház, Hollywood Multiplex Mozi (1097 Budapest, Könyves Kálmán krt. 12-14.) 


Windows 2000 alapú, Internet-kész hálózati infrastruktúra kialakítása 

Időpont: 2001. 03. 07. 

Az előadásban áttekintjük a Windows 2000 alapú hálózati infrastruktúrát. A nap során egy helyi munkacso- 
portos környezetből kiindulva felépítünk egy címtár alapú, útválasztóval, később tűzfallal az Internetre kap- 
csolódó hálózatot, amely távoli telephelyeket is képes összekötni a Virtuális Magánhálózatok révén. 


Vállalati E-business rendszerek Windows 2000 alapokon 

Időpont: 2001. 03. 21. 

Ezen az előadáson üzleti folyamatok automatizálásával foglalkozunk. Megoldásokat mutatunk be egymás mel- 
tására. Az előadás első felében néhány alapvető problémát oldunk meg, mint a meglévő rendszerekkel törté- 
nő egyszerű adatcsere, az üzleti tranzakciók kezelése, vagy az üzleti kommunikáció biztonságossá tétele; a 
szünet után pedig egy nagyobb lélegzetű, cégek közötti üzleti integrációs problémát dolgozunk ki. 


A Windows 2000 alapú hálózatok biztonsági kérdései 

Időpont: 2001. 04. 04. 

Ezen az előadáson a Windows 2000 operációs rendszer nyújtotta biztonsági szolgáltatásokkal foglalkozunk. Egy 
egygépes rendszerből kiindulva a nap során fokozatosan eljutunk egy nagyvállalati rendszer címtár segítségével 
felügyelt, PKI infrastruktúrán alapuló rendszerig. Sok egyéb mellett lépésről-lépésre bemutatjuk, hogyan lehet 
engedélyezni az intelligens kártya alapú felhasználói bejelentkezést, hogyan kommunikálhatnak titkosítva a ki- 
szolgáló farm elemei egymással, és hogyan küldhetünk egymásnak titkosított vagy digitálisan aláírt levelet. 


Ismeretkezelő és csoportmunka-megoldások Microsoft-platformon 

Időpont: 2001. 04. 18. 

A szemináriumon egy tipikus Windows NT/2000 fájl- és nyomtatókiszolgálókat üzemeltető, Office-t és e-ma- 
ilt használó vállalati környezetből kiindulva fokozatosan építünk fel egy fejlett csoportmunka-, ismeretkeze- 
lő és kommunikációs megoldásokat alkalmazó rendszert. 


Microsoft Üzemeltetői Konferencia 

Időpont: 2001. 04. 25. 

A konferencia elsősorban üzemeltetési vezetőknek és rendszer üzemeltetőknek szól. Segítséget nyújt a nagy- és kö- 
zépvállalatok informatikusainak és rendszergazdáinak, hogy a már meglévő Microsoft technológiákra épülő rend- 
szereiket még megbízhatóbban és egyszerűbben üzemeltethessék. Szeretnénk bemutatni és átadni mindazt a tu- 
dást, ami a Microsoftnál és partnereinél az üzemeltetési és terméktámogatási gyakorlat során felhalmozódott. 


Rendszerfelügyelet Windows 2000 környezetben 

Időpont: 2001. 05. 02. 

Az előadás a Windows 2000 alapú vállalati környezetek rendszerfelügyeleti és üzemeltetési kérdéseit tárgyal- 
ja. A gyakorlatias megközelítésű előadáson egy kiépített Windows 2000 Active Directory, Systems Manage- 
ment Server (SMS) 2.0 és Microsoft Operations Manager környezetben mutatjuk be az asztali gépek és alkal- 
mazások, illetve a kiszolgálók felügyeletét és a napi üzemeltetési teendőket. 


Üzleti Intelligencia: adatraktárak létrehozása és az adatok elemzése 

Időpont: 2001. 05. 16. 

Minden vállalat használ adatbáziskezelőt, de vajon kihasználja-e a felhalmozott üzleti célú adatokban rejlő 
információkat? Az előadások az adattárház kezelés folyamatának legfontosabb lépéseit tekintik át. Ismerte- 
tett technológiák: Data Transformation Services, OLAP kiszolgáló (Analysis Services), MDX, ADO DM. 
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selejtmenit 
gyártásri 
Rendszer- 
felügyeletmen 
hálózatról C 

Feltöorhetetlen 

hálózatról (C2)? 


Elérhetetlen, de megközelíthető célok. Az első kettő elérésében sajnos nem segít- 
hetünk. De a harmadik cél megközelítésében sokat tehetünk Önért. Világszínvonalú, 
egyedi Security tanfolyamainkon megtudhatja, mitől döglik a hacker! 














1. Biztonsági technológiák 3. Hálózatunk védelme a támadásokkal szemben 
rendszergazdáknak, 3 nap biztonsággal foglalkozó szakembereknek, 3 nap 
e Titkosítási algoritmusok (DES, RSA, MD5 stb.) elmélete és gyakorlata e  Kalóz-eszközkészlet (Denial Of Service, Buffer 


e Az authentikáció biztonsága (Kerberos, NTLM, NTLMv2) 

s — A nyílt kulcsú titkosítási technológia nagyvállalati, gyakorlati alkalmazása e. 
(Certificate Server, SmartCard, biometrikus azonosítás) 

e — Biztonságot növelő technológiák bevezetése (IPSec, VPN, LZTP. Encrypting 


Overrun, hálózatelemzés, trójai falovak, vírusok, jelszófeltörés, hátsó ajtók) 
A Windows 2000 biztonsági elemei (fájlrendszerek, regisztrációs adat- 
bázis, hálózati adatforgalom) 

Védekezés: tűzfalak, proxyk 


File System stb.) s — Aktív védekezés: Intrusion Detection 
4. Programozzunk biztonságosan! 
2. Biztonságos levelezőrendszer kialakítása MS Exchange alapokon programozók számára, 3 nap 
gyakorlott Exchange endszergazdák számára, 3 nap s Elmélet: védett mód, kernel, memóriakezelés 
e Titkosítás és digitális aláírás az elektronikus levelezésben (S/MIME) s Programozási gyakorlatok, rosszul és jól megírt kódok 
e — Az Exchange Server védelme, adminisztratív szerepek, jogosultságok, s A Buffer overrun hatásai user és (app es service)-4-kernel módban 
mentés, visszaállítás, journaling e — RFC implementation errors 
o tűzfal vs. Exchange Server, SMTP relay beállítások, spam védelem, SSL, e — JAVA, ActriveX, homokozó, scriptek 
TSL, nyílt kulcsú titkosítás felhasználása, MAPI, POP3, IMAP, OWA, LDAP s — Worm vírusok elemzése (lloveyou) 


protokollok veszélyei. . 
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